Re: [PATCH 03/12] xfs: rescan the AGs if incore delalloc counter is negative

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Oct 12, 2026 at 06:16:37AM -0700, Christoph Hellwig wrote:
> On Sun, Oct 11, 2026 at 10:59:38PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > LOLLM complains that percpu_counter_sum can return a negative number but
> > we instead misinterpret that into a huge unsigned value and do bad
> > things to fdblocks.  It shouldn't do that, so let's add a retry loop and
> > an attempt to freeze the filesystem to (hopefully) zero out the incore
> > delalloc counter.  It probably won't work, but at least failing the
> > repair beats doing the wrong thing.
> 
> I wonder how we could even end up with a negative value here, given
> that we should not see live changes.  I.e. might it make more sense
> to just treat the theoretical negative values as 0 instead of a never
> exercises retry path?

I'm not sure how in practice you'd end up with a negative value in
the incore delalloc count.  I changed it to try to freeze the filesystem
on the off chance that the summary counter corruption is mirrored in an
xfs_inode somewhere, and that purging them out will fix it.  Or take
down the fs :P

But I could just bail entirely if the incore count is negative, since
in theory this situation Should Never Happen(tm):

	delayed = percpu_counter_sum(&mp->m_delalloc_blks);
	if (delayed < 0) {
		ASSERT(delayed >= 0);
		xchk_set_incomplete(sc);
		return -EFSCORRUPTED;
	}

Perhaps a better long term fix would be to sum the i_delayed_blks
counters across the entire xfs_inode cache and correct the incore
counter, but that sounds expensive for something that we shouldn't have
to worry about unless the CPU forgets arithmetic.

Oh hey, I should do the same for m_delalloc_rtextents.  Let me go fix
that too.

--D