Skip to content

Commit 94f9a03

Browse files
adam900710kdave
authored andcommitted
btrfs-progs: tune convert-bgt: fix uninitialized value which leads to failed resume
[BUG] There is a bug report that btrfstune failed to resume an interrupted conversion. I reproduced locally with an image which is half converted, in extent tree there are 3 block groups: item 0 key (1048576 BLOCK_GROUP_ITEM 4194304) itemoff 3971 itemsize 24 item 3 key (5242880 BLOCK_GROUP_ITEM 8388608) itemoff 3881 itemsize 24 item 8 key (13631488 BLOCK_GROUP_ITEM 8388608) itemoff 3687 itemsize 24 And 4 block groups in the new block group tree: item 0 key (22020096 BLOCK_GROUP_ITEM 117440512) itemoff 3971 itemsize 24 item 1 key (139460608 BLOCK_GROUP_ITEM 117440512) itemoff 3947 itemsize 24 item 2 key (256901120 BLOCK_GROUP_ITEM 117440512) itemoff 3923 itemsize 24 item 3 key (374341632 BLOCK_GROUP_ITEM 117440512) itemoff 3899 itemsize 24 Then resume the conversion will fail with the following error: $ btrfstune --convert-to-block-group-tree /dev/test/scratch1 ERROR: failed to find block group for bytenr 13631488 ERROR: failed to convert the filesystem to block group tree feature ERROR: btrfstune failed extent buffer leak: start 23224320 len 4096 Meanwhile as the above dump tree shows, the block group item 13631488 is indeed in the old extent tree. [CAUSE] During opening of such half-converted fs, btrfs will load the block group items in two steps: - read_old_block_groups_from_root() Which will load the block groups from the old tree (extent tree in the above case). - read_block_groups_from_root() Which will load the block groups from the new tree (block group tree in the above case). The problem is inside read_old_block_groups_from_root(), which uses an on-stack @key to not only indicate where to start the search. Unfortunately we didn't initialize that @key structure, resulting in garbage initial value, which can be larger than all block group items in the extent tree. So these block group items are not loaded into our block group cache, then leading to the conversion failure, as we rely on the block group cache built at opening time. [FIX] Fix the uninitialized @key by initializing it to zero, as we expect to search for the first block group item. So that the block group items in the old tree can be properly loaded. Reported-by: Tine Mezgec <[email protected]> Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]>
1 parent 835ff5b commit 94f9a03

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

kernel-shared/extent-tree.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2860,7 +2860,7 @@ static int read_old_block_groups_from_root(struct btrfs_fs_info *fs_info,
28602860
struct btrfs_root *root)
28612861
{
28622862
struct btrfs_path path = {0};
2863-
struct btrfs_key key;
2863+
struct btrfs_key key = { 0 };
28642864
struct cache_extent *ce;
28652865
/* The last block group bytenr in the old root. */
28662866
u64 last_bg_in_old_root;

0 commit comments

Comments
 (0)