1 From 10950929e994c5ecee149ff0873388d3c98f12b5 Mon Sep 17 00:00:00 2001
2 From: Qu Wenruo <wqu@suse.com>
3 Date: Fri, 23 Nov 2018 09:06:36 +0800
4 Subject: btrfs: tree-checker: Don't check max block group size as current max chunk size limit is unreliable
6 From: Qu Wenruo <wqu@suse.com>
8 commit 10950929e994c5ecee149ff0873388d3c98f12b5 upstream.
11 A completely valid btrfs will refuse to mount, with error message like:
12 BTRFS critical (device sdb2): corrupt leaf: root=2 block=239681536 slot=172 \
13 bg_start=12018974720 bg_len=10888413184, invalid block group size, \
14 have 10888413184 expect (0, 10737418240]
16 This has been reported several times as the 4.19 kernel is now being
17 used. The filesystem refuses to mount, but is otherwise ok and booting
20 Btrfs check returns no error, and all kernels used on this fs is later
21 than 2011, which should all have the 10G size limit commit.
24 For a 12 devices btrfs, we could allocate a chunk larger than 10G due to
25 stripe stripe bump up.
28 |- max_stripe_size = 1G
29 |- max_chunk_size = 10G
31 |- if (1G * 11 > 10G) {
32 stripe_size = 976128930;
33 stripe_size = round_up(976128930, SZ_16M) = 989855744
35 However the final stripe_size (989855744) * 11 = 10888413184, which is
36 still larger than 10G.
39 For the comprehensive check, we need to do the full check at chunk read
40 time, and rely on bg <-> chunk mapping to do the check.
42 We could just skip the length check for now.
44 Fixes: fce466eab7ac ("btrfs: tree-checker: Verify block_group_item")
45 Cc: stable@vger.kernel.org # v4.19+
46 Reported-by: Wang Yugui <wangyugui@e16-tech.com>
47 Signed-off-by: Qu Wenruo <wqu@suse.com>
48 Reviewed-by: David Sterba <dsterba@suse.com>
49 Signed-off-by: David Sterba <dsterba@suse.com>
50 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
53 fs/btrfs/tree-checker.c | 8 +++-----
54 1 file changed, 3 insertions(+), 5 deletions(-)
56 --- a/fs/btrfs/tree-checker.c
57 +++ b/fs/btrfs/tree-checker.c
58 @@ -348,13 +348,11 @@ static int check_block_group_item(struct
61 * Here we don't really care about alignment since extent allocator can
62 - * handle it. We care more about the size, as if one block group is
63 - * larger than maximum size, it's must be some obvious corruption.
64 + * handle it. We care more about the size.
66 - if (key->offset > BTRFS_MAX_DATA_CHUNK_SIZE || key->offset == 0) {
67 + if (key->offset == 0) {
68 block_group_err(fs_info, leaf, slot,
69 - "invalid block group size, have %llu expect (0, %llu]",
70 - key->offset, BTRFS_MAX_DATA_CHUNK_SIZE);
71 + "invalid block group size 0");