- 06 Aug, 2018 40 commits
-
-
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:
David Sterba <dsterba@suse.com>
-
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:
Nikolay Borisov <nborisov@suse.com> 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:
-
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
This argument is unused. 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:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where the fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function always uses the leaf's extent_buffer which already contains a reference to the fs_info. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where the fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This argument is unused. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction from where the fs_info can be referenced. No functional change. 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
This function is always called with a valid transaction handle from where fs_info can be referenced. So remove the redundant argument. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction so there is no need to duplicate the fs_info, we can reference it directly from the trans handle. No functional changes. Signed-off-by:
-
