Re: transaction assertion failure in next-20251103

[Dave Chinner <david@fromorbit.com>]

On Tue, Nov 04, 2025 at 03:53:49PM +0000, Matthew Wilcox wrote:
> Two runs of xfstests, two assertion failures.  One while running
> generic/083, one while running generic/561.
> 
> Here's the g/561 failure:
> 
> generic/561       run fstests generic/561 at 2025-11-03 22:20:18
.....
> XFS (vdc): Corruption of in-memory data (0x8) detected at xfs_trans_mod_sb+0x2a4/0x310 (fs/xfs/xfs_trans.c:353).  Shutting down filesystem.
> XFS (vdc): Please unmount the filesystem and rectify the problem(s)
> XFS: Assertion failed: tp->t_blk_res >= tp->t_blk_res_used, file: fs/xfs/xfs_trans.c, line: 120
....
>  xfs_trans_dup+0x258/0x270
>  xfs_trans_roll+0x48/0x120
>  xfs_defer_trans_roll+0x5f/0x1a0
>  xfs_defer_finish_noroll+0x3d5/0x5d0
>  xfs_trans_commit+0x4e/0x70
>  xfs_iomap_write_unwritten+0xe5/0x350

So we have a block reservation for a double split of the BMBT
(which technically cannot happen for a double adjacent record
insert) yet we apparently exhausted the entire block allocation.

Thing is, modifications to tp->t_blk_res_used can only be done
through xfs_trans_mod_sb() during the transaction, which
does:

        case XFS_TRANS_SB_FDBLOCKS:
                /*
                 * Track the number of blocks allocated in the transaction.
                 * Make sure it does not exceed the number reserved. If so,
                 * shutdown as this can lead to accounting inconsistency.
                 */
                if (delta < 0) {
                        tp->t_blk_res_used += (uint)-delta;
                        if (tp->t_blk_res_used > tp->t_blk_res)
                                xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); 

Which will shut down the filesystem the moment a block allocation
overrun occurs. This should happen long before we get to the
transaction commit code...

IOWs, the internal runtime transaction accounting check whenever
tp->t_blk_res_used is updated passed just fine, but it was then
detected as broken a short time later at transaction commit time.

This implies something external modified either tp->t_blk_res or
tp->t_blk_res_used between the last time it was modified by the
filesystem and when it bounds checked and when the transaction was
committed and rolled.

This, to me, smells of external memory corruption, not an XFS bug...

> CPU: 3 UID: 0 PID: 338999 Comm: kworker/3:12 Not tainted 6.18.0-rc4-next-2025110

... and you are testing on a -next kernel, so it's entirely possible
that there is newly introduced memory corruption bug somewhere
outside of XFS.

Can you reproduce this on a vanilla v6.18-rc4 kernel?

-Dave.
-- 
Dave Chinner
david@fromorbit.com