On 2019/11/18 5:56 PM, Nikolay Borisov wrote:
On 18.11.19 г. 7:56 ч., damenly.su@xxxxxxxxx wrote:From: Su Yue <Damenly_Su@xxxxxxx> while excluding super stripes from one block group, the logical bytenr should not be excluded if the block group's start + length equals the bytenr since the bytenr is not belong to the block group. This is insipred by same bugous code of btrfs-progs. The fuzz image is rejected to be mounted by tree-checker, but not bad to enhance the check in practice. Signed-off-by: Su Yue <Damenly_Su@xxxxxxx> --- fs/btrfs/block-group.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 1e521db3ef56..54f970f459f5 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -1539,7 +1539,7 @@ static int exclude_super_stripes(struct btrfs_block_group_cache *cache) while (nr--) { u64 start, len; - if (logical[nr] > cache->start + cache->length) + if (logical[nr] >= cache->start + cache->length) continue; if (logical[nr] + stripe_len <= cache->start)Is this check necessary at all, since btrfs_rmap_block already contains a check which ensures the physical address passed is withing the range of the given chunk, which in turn means all logical addresses derived in btrfs_rmap_block with: bytenr = chunk_start + stripe_nr * rmap_len; will be within this block group?
Yes, you're right. Drop this bad patch. Got sick, sorry for the late reply.
