Re: [PATCH v2] ext4: synchronize free block counter when detecting corruption

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Oct 10, 2025 at 03:38:00AM -0400, Albin Babu Varghese wrote:
> When ext4_mb_generate_buddy() detects block group descriptor
> corruption (free block count mismatch between descriptor and
> bitmap), it corrects the in-memory group descriptor (grp->bb_free)
> but does not synchronize the percpu free clusters counter.

Actually, we do.  This happens in ext4_mark_group_bitmap_corrupted in
fs/ext4/super.c.

	if (flags & EXT4_GROUP_INFO_BBITMAP_CORRUPT) {
		ret = ext4_test_and_set_bit(EXT4_GROUP_INFO_BBITMAP_CORRUPT_BIT,
					    &grp->bb_state);
		if (!ret)
			percpu_counter_sub(&sbi->s_freeclusters_counter,
					   grp->bb_free);
	}

So we've *already* subtracted out the blocks that were in the block
group which we've busied out.

> This causes delayed allocation to read stale counter values when
> checking for available space. The allocator believes space is
> available based on the stale counter, makes reservation promises,
> but later fails during writeback when trying to allocate actual
> blocks from the bitmap. This results in "Delayed block allocation
> failed" errors and potential system crashes.

I suspect there is something else going on with s_freeclusters_counter
being incorrect, but adding an additional correction to
s_freeclusters_counter is not the answer.

How is the system crashing?  If we have errors=continue, then we
really shouldn't let the system crash.  If there is delayed allocation
failures, the user might lose data, but if the user really cares about
that, they shouldn't be using errors=continue.

						- Ted