Re: flakey assert failures in xfs/538 in for-next

[Christoph Hellwig <hch@lst.de>]

On Wed, Jul 16, 2025 at 08:38:12AM -0700, Darrick J. Wong wrote:
> I've seen this happen maybe once or twice, I think the problem is that
> the symlink xfs_bmapi_write fails to allocate enough blocks to store the
> symlink target, doesn't notice, and then the actual target write runs
> out of blocks before it runs out of pathlen and kaboom.
> 
> Probably the right answer is to ENOSPC if we can't allocate blocks, but
> I guess we did reserve free space so perhaps we just keep bmapi'ing
> until we get all the space we need?
> 
> The weird part is that XFS_SYMLINK_MAPS should be large enough to fit
> all the target we need, so ... I don't know if bmapi_write is returning
> fewer than 3 nmaps because it hit ENOSPC or what?
> 
> (and because I can't reproduce it reliably, I have not investigated
> further :()

I guess the recent cleanups are not too blame then, or just slightly
changed the timing for me to have a streak to frequently hit it.

xfs/538 is the alloc minlen test that injects getting back the minlen
or failing allocations if minlen > 1.  I guess that interacts badly
somehow with the rather uncommon multi-map allocations.  The only
other one is xfs_da_grow_inode_int, and that only for directories
with a larger directory block size, and as a fallback when the contig
allocations fails.  It might be worth crafting a test doing a lot
of symlinking while doing that error injetion to trigger it more
reliably.