Re: [PATCH] btrfs: block group: do not exclude bytenr adjacent to block group

[Su Yue <Damenly_Su@gmx.com>]

On 2019/11/18 5:56 PM, Nikolay Borisov wrote:
>
>
> On 18.11.19 г. 7:56 ч., damenly.su@gmail.com wrote:
>> From: Su Yue <Damenly_Su@gmx.com>
>>
>> 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@gmx.com>
>> ---
>>   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.