Re: [PATCH RFC 04/17] ext4: fix incorrect block bitmap free clusters update on metadata overlap

[Baokun Li <libaokun@linux.alibaba.com>]

在 2026/5/9 05:17, sashiko-bot@kernel.org 写道:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Incomplete Error Recovery / Buddy Cache Inconsistency
> - [High] State Inconsistency / Global Counter Desync
> --
>
> commit 3b816cdf85c67263b3c35b6097c935d14091d27d
> Author: Baokun Li <libaokun@linux.alibaba.com>
>
> ext4: fix incorrect block bitmap free clusters update on metadata overlap
>
> In ext4_mb_mark_diskspace_used(), when the allocator detects that the
> allocated blocks overlap with filesystem metadata, it enters an error
> recovery path that marks these blocks as used in the bitmap via
> ext4_mb_mark_context() with flags=0.
>
> [ ... ]
>
>> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
>> --- a/fs/ext4/mballoc.c
>> +++ b/fs/ext4/mballoc.c
>> @@ -4228,7 +4228,7 @@ ext4_mb_mark_diskspace_used(struct ext4_allocation_context *ac, handle_t *handle
>>  					   ac->ac_b_ex.fe_group,
>>  					   ac->ac_b_ex.fe_start,
>>  					   ac->ac_b_ex.fe_len,
>> -					   0, NULL);
>> +					   EXT4_MB_BITMAP_MARKED_CHECK, NULL);
> This isn't a regression introduced by this patch, but by passing NULL for
> the changed pointer, the global sbi->s_freeclusters_counter is not
> decremented for these leaked blocks.
>
> Because the group descriptors are decremented to reflect the leaked blocks
> but the global counter is not, does this cause the global free space counter
> to permanently overestimate available space?
>
> Could this allow ext4_claim_free_clusters() to succeed when there is
> actually no space, leading to delayed allocation ENOSPC errors during
> writeback?
>
> Additionally, if ext4_mb_mark_diskspace_used() returns -EFSCORRUPTED, the
> caller ext4_mb_new_blocks() will handle the failure by invoking
> ext4_discard_allocated_blocks().
>
> Since ext4_discard_allocated_blocks() calls mb_free_blocks() to clear the
> bits in the in-memory buddy cache and/or restores them to the preallocation
> space, doesn't this completely defeat the attempt to leak the blocks here?
>
> Will the next allocation request for this block group find the identical
> overlapping blocks in the buddy cache, allocate them, and hit the same
> metadata overlap check again?
>
> Could this be fixed by clearing ac->ac_b_ex.fe_len and ac->ac_f_ex.fe_len
> before returning the error, to prevent the rollback function from freeing
> the blocks in the buddy cache?

Indeed, there are some issues with this error path handling itself,
and I will add a patch to fix it in the next version.


Thanks,
Baokun

>
>>  		if (!err)
>>  			err = -EFSCORRUPTED;
>>  		return err;