- 06 Aug, 2018 40 commits
-
-
Nikolay Borisov authored
Following the removal of the v0 handling code let's be courteous and print an error message when such extents are handled. In the cases where we have a transaction just abort it, otherwise just call btrfs_handle_fs_error. Both cases result in the FS being re-mounted RO. In case the error handling would be too intrusive, leave the BUG_ON in place, like extent_data_ref_count, other proper handling would catch that earlier. Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Nikolay Borisov authored
The v0 compat code was introduced in commit 5d4f98a2 ("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") 9 years ago, which was merged in 2.6.31. This means that the code is there to support filesystems which are _VERY_ old and if you are using btrfs on such an old kernel, you have much bigger problems. This coupled with the fact that no one is likely testing/maintining this code likely means it has bugs lurking. All things considered I think 43 kernel releases later it's high time this remnant of the past got removed. This patch removes all code wrapped in #ifdefs but leaves the BUG_ONs in case we have a v0 with no support intact as a sort of safety-net. Signed-off-by:
-
Chengguang Xu authored
It's only coding style fix not functinal change. When if/else has only one statement then the braces are not needed. Signed-off-by:
Chengguang Xu <cgxu519@gmx.com> Reviewed-by:
-
Chengguang Xu authored
It's not good to override the error code when failing from btrfs_getxattr() in btrfs_get_acl() because it hides the real reason of the failure. Signed-off-by:
-
Chengguang Xu authored
There is no chance to get into -ERANGE error condition because we first call btrfs_getxattr to get the length of the attribute, then we do a subsequent call with the size from the first call. Between the 2 calls the size shouldn't change. So remove the unnecessary -ERANGE error check. Signed-off-by:
-
Chengguang Xu authored
In btrfs_get_acl() the first call of btr_getxattr() is for getting the length of attribute, the value buffer is never used in this case. So it's better to replace empty string with NULL. Signed-off-by:
-
Chengguang Xu authored
The caller of btrfs_get_acl() checks error condition so there is no impact from this change. In practice there is no chance to get into default case of switch statement because VFS has already checked the type. Signed-off-by:
-
Su Yue authored
If type of extent_inline_ref found is not expected, filesystem may have been corrupted, should return EUCLEAN instead of EINVAL. Signed-off-by:
Su Yue <suy.fnst@cn.fujitsu.com> Reviewed-by:
-
Goldwyn Rodrigues authored
struct kiocb carries the ki_pos, so there is no need to pass it as a separate function parameter. generic_file_direct_write() increments ki_pos, so we now assign pos after the function. Signed-off-by:
Goldwyn Rodrigues <rgoldwyn@suse.com> Reviewed-by:
Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> [ rename to btrfs_buffered_write ] Signed-off-by:
-
Su Yue authored
For easier debugging, print eb->start if level is invalid. Also make clear if bytenr found is not expected. Signed-off-by:
-
Nikolay Borisov authored
Currently the function uses 2 goto labels to properly handle allocation failures. This could be simplified by simply re-arranging the code so that allocations are the in the beginning of the function. This allows to use simple return statements. No functional changes. Signed-off-by:
-
Qu Wenruo authored
[BUG] Under certain KVM load and LTP tests, it is possible to hit the following calltrace if quota is enabled: BTRFS critical (device vda2): unable to find logical 8820195328 length 4096 BTRFS critical (device vda2): unable to find logical 8820195328 length 4096 WARNING: CPU: 0 PID: 49 at ../block/blk-core.c:172 blk_status_to_errno+0x1a/0x30 CPU: 0 PID: 49 Comm: kworker/u2:1 Not tainted 4.12.14-15-default #1 SLE15 (unreleased) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] task: ffff9f827b340bc0 task.stack: ffffb4f8c0304000 RIP: 0010:blk_status_to_errno+0x1a/0x30 Call Trace: submit_extent_page+0x191/0x270 [btrfs] ? btrfs_create_repair_bio+0x130/0x130 [btrfs] __do_readpage+0x2d2/0x810 [btrfs] ? btrfs_create_repair_bio+0x130/0x130 [btrfs] ? run_one_async_done+0xc0/0xc0 [btrfs] __extent_read_full_page+0xe7/0x100 [btrfs] ? run_one_async_done+0xc0/0xc0 [btrfs] read_extent_buffer_pages+0x1ab/0x2d0 [btrfs] ? run_one_async_done+0xc0/0xc0 [btrfs] btree_read_extent_buffer_pages+0x94/0xf0 [btrfs] read_tree_block+0x31/0x60 [btrfs] read_block_for_search.isra.35+0xf0/0x2e0 [btrfs] btrfs_search_slot+0x46b/0xa00 [btrfs] ? kmem_cache_alloc+0x1a8/0x510 ? btrfs_get_token_32+0x5b/0x120 [btrfs] find_parent_nodes+0x11d/0xeb0 [btrfs] ? leaf_space_used+0xb8/0xd0 [btrfs] ? btrfs_leaf_free_space+0x49/0x90 [btrfs] ? btrfs_find_all_roots_safe+0x93/0x100 [btrfs] btrfs_find_all_roots_safe+0x93/0x100 [btrfs] btrfs_find_all_roots+0x45/0x60 [btrfs] btrfs_qgroup_trace_extent_post+0x20/0x40 [btrfs] btrfs_add_delayed_data_ref+0x1a3/0x1d0 [btrfs] btrfs_alloc_reserved_file_extent+0x38/0x40 [btrfs] insert_reserved_file_extent.constprop.71+0x289/0x2e0 [btrfs] btrfs_finish_ordered_io+0x2f4/0x7f0 [btrfs] ? pick_next_task_fair+0x2cd/0x530 ? __switch_to+0x92/0x4b0 btrfs_worker_helper+0x81/0x300 [btrfs] process_one_work+0x1da/0x3f0 worker_thread+0x2b/0x3f0 ? process_one_work+0x3f0/0x3f0 kthread+0x11a/0x130 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x35/0x40 BTRFS critical (device vda2): unable to find logical 8820195328 length 16384 BTRFS: error (device vda2) in btrfs_finish_ordered_io:3023: errno=-5 IO failure BTRFS info (device vda2): forced readonly BTRFS error (device vda2): pending csums is 2887680 [CAUSE] It's caused by race with block group auto removal: - There is a meta block group X, which has only one tree block The tree block belongs to fs tree 257. - In current transaction, some operation modified fs tree 257 The tree block gets COWed, so the block group X is empty, and marked as unused, queued to be deleted. - Some workload (like fsync) wakes up cleaner_kthread() Which will call btrfs_delete_unused_bgs() to remove unused block groups. So block group X along its chunk map get removed. - Some delalloc work finished for fs tree 257 Quota needs to get the original reference of the extent, which will read tree blocks of commit root of 257. Then since the chunk map gets removed, the above warning gets triggered. [FIX] Just let btrfs_delete_unused_bgs() skip block group which still has pinned bytes. However there is a minor side effect: currently we only queue empty blocks at update_block_group(), and such empty block group with pinned bytes won't go through update_block_group() again, such block group won't be removed, until it gets new extent allocated and removed. Signed-off-by:
Qu Wenruo <wqu@suse.com> Reviewed-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
-
Geert Uytterhoeven authored
With gcc 4.1.2: fs/btrfs/inode-map.c: In function ‘btrfs_unpin_free_ino’: fs/btrfs/inode-map.c:241: warning: ‘count’ may be used uninitialized in this function While this warning is a false-positive, it can easily be killed by refactoring the code. Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
-
Arnd Bergmann authored
While the regular inode timestamps all use timespec64 now, the i_otime field is btrfs specific and still needs to be converted to correctly represent times beyond 2038. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Arnd Bergmann authored
The transaction times were changed to ktime_get_real_seconds to avoid the y2038 overflow, but they still have a minor problem when they go backwards or jump due to settimeofday() or leap seconds. This changes the transaction handling to instead use ktime_get_seconds(), which returns a CLOCK_MONOTONIC timestamp that has neither of those problems. Signed-off-by:
-
Qu Wenruo authored
We used to call btrfs_file_extent_inline_len() to get the uncompressed data size of an inlined extent. However this function is hiding evil, for compressed extent, it has no choice but to directly read out ram_bytes from btrfs_file_extent_item. While for uncompressed extent, it uses item size to calculate the real data size, and ignoring ram_bytes completely. In fact, for corrupted ram_bytes, due to above behavior kernel btrfs_print_leaf() can't even print correct ram_bytes to expose the bug. Since we have the tree-checker to verify all EXTENT_DATA, such mismatch can be detected pretty easily, thus we can trust ram_bytes without the evil btrfs_file_extent_inline_len(). Signed-off-by:
-
Nikolay Borisov authored
When a new extent buffer is allocated there are a few mandatory fields which need to be set in order for the buffer to be sane: level, generation, bytenr, backref_rev, owner and FSID/UUID. Currently this is open coded in the callers of btrfs_alloc_tree_block, meaning it's fairly high in the abstraction hierarchy of operations. This patch solves this by simply moving this init code in btrfs_init_new_buffer, since this is the function which initializes a newly allocated extent buffer. No functional changes. Signed-off-by:
-
Qu Wenruo authored
Commit f8f84b2d ("btrfs: index check-integrity state hash by a dev_t") changed how btrfsic indexes device state. Now we need to access device->bdev->bd_dev, while for degraded mount it's completely possible to have device->bdev as NULL, thus it will trigger a NULL pointer dereference at mount time. Fix it by checking if the device is degraded before accessing device->bdev->bd_dev. There are a lot of other places accessing device->bdev->bd_dev, however the other call sites have either checked device->bdev, or the device->bdev is passed from btrfsic_map_block(), so it won't cause harm. Fixes: f8f84b2d ("btrfs: index check-integrity state hash by a dev_t") Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from the passed transaction handle. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from the passed bg cache. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from trans since the function is always called within a valid transaction. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced directly from the transaction handle since it's always valid. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from the passed transaction handle, since it's always valid. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from the passed transaction handle, since it's always valid. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from the passed block group. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from the passed block group. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from trans since the function is always called within a transaction. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from trans since the function is always called within a transaction. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
It can always be referneced from the passed transaction handle since it's always valid. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
fs_info can be refenreced from the transaction handle, since it's always valid. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
The argument is no longer used so remove it. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle so fs_info can be referenced from there. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction from where fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function already takes a transaction which holds a reference to the fs_info struct. Use that reference and remove the extra arg. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
fs_info can be referenced from the transaction handle, which is always valid. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle so we can reference the fs_info from there. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where we can reference fs_info. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where we can reference the fs_info. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where fs_info can be referenced. No functional changes. Signed-off-by:
-
