Skip to content

Commit 76a66ba

Browse files
adam900710kdave
authored andcommitted
btrfs: don't use btrfs_chunk::sub_stripes from disk
[BUG] There are two reports (the earliest one from LKP, a more recent one from kernel bugzilla) that we can have some chunks with 0 as sub_stripes. This will cause divide-by-zero errors at btrfs_rmap_block, which is introduced by a recent kernel patch ac06773 ("btrfs: merge calculations for simple striped profiles in btrfs_rmap_block"): if (map->type & (BTRFS_BLOCK_GROUP_RAID0 | BTRFS_BLOCK_GROUP_RAID10)) { stripe_nr = stripe_nr * map->num_stripes + i; stripe_nr = div_u64(stripe_nr, map->sub_stripes); <<< } [CAUSE] From the more recent report, it has been proven that we have some chunks with 0 as sub_stripes, mostly caused by older mkfs. It turns out that the mkfs.btrfs fix is only introduced in 6718ab4d33aa ("btrfs-progs: Initialize sub_stripes to 1 in btrfs_alloc_data_chunk") which is included in v5.4 btrfs-progs release. So there would be quite some old filesystems with such 0 sub_stripes. [FIX] Just don't trust the sub_stripes values from disk. We have a trusted btrfs_raid_array[] to fetch the correct sub_stripes numbers for each profile and that are fixed. By this, we can keep the compatibility with older filesystems while still avoid divide-by-zero bugs. Reported-by: kernel test robot <[email protected]> Reported-by: Viktor Kuzmin <[email protected]> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216559 Fixes: ac06773 ("btrfs: merge calculations for simple striped profiles in btrfs_rmap_block") CC: [email protected] # 6.0 Reviewed-by: Su Yue <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]>
1 parent 2398091 commit 76a66ba

File tree

1 file changed

+11
-1
lines changed

1 file changed

+11
-1
lines changed

fs/btrfs/volumes.c

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7142,13 +7142,15 @@ static int read_one_chunk(struct btrfs_key *key, struct extent_buffer *leaf,
71427142
u64 devid;
71437143
u64 type;
71447144
u8 uuid[BTRFS_UUID_SIZE];
7145+
int index;
71457146
int num_stripes;
71467147
int ret;
71477148
int i;
71487149

71497150
logical = key->offset;
71507151
length = btrfs_chunk_length(leaf, chunk);
71517152
type = btrfs_chunk_type(leaf, chunk);
7153+
index = btrfs_bg_flags_to_raid_index(type);
71527154
num_stripes = btrfs_chunk_num_stripes(leaf, chunk);
71537155

71547156
#if BITS_PER_LONG == 32
@@ -7202,7 +7204,15 @@ static int read_one_chunk(struct btrfs_key *key, struct extent_buffer *leaf,
72027204
map->io_align = btrfs_chunk_io_align(leaf, chunk);
72037205
map->stripe_len = btrfs_chunk_stripe_len(leaf, chunk);
72047206
map->type = type;
7205-
map->sub_stripes = btrfs_chunk_sub_stripes(leaf, chunk);
7207+
/*
7208+
* We can't use the sub_stripes value, as for profiles other than
7209+
* RAID10, they may have 0 as sub_stripes for filesystems created by
7210+
* older mkfs (<v5.4).
7211+
* In that case, it can cause divide-by-zero errors later.
7212+
* Since currently sub_stripes is fixed for each profile, let's
7213+
* use the trusted value instead.
7214+
*/
7215+
map->sub_stripes = btrfs_raid_array[index].sub_stripes;
72067216
map->verified_stripes = 0;
72077217
em->orig_block_len = btrfs_calc_stripe_length(em);
72087218
for (i = 0; i < num_stripes; i++) {

0 commit comments

Comments
 (0)