Re: generic/753 crash with LARP

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

On Sat, Feb 28, 2026 at 04:54:25PM +0530, Ravi Singh wrote:
> On Thu, Feb 26, 2026 at 11:01 AM Darrick J. Wong <djwong@kernel.org> wrote:
> 
> > Hrm.  Where should we insert a xfs_force_shutdown call to reproduce the
> > problem?  I can get this to trip, but only after 18-25 minutes of
> > letting g/753 run.
> 
> I'm able to reproduce the crash reliably with the patch below.
> With this change, g/753 crash quickly.
> Please see if this works for you as well.
> 
> diff --git a/fs/xfs/xfs_attr_item.c b/fs/xfs/xfs_attr_item.c
> index 354472bf4..15eefa3e1 100644
> --- a/fs/xfs/xfs_attr_item.c
> +++ b/fs/xfs/xfs_attr_item.c
> @@ -500,6 +500,17 @@ xfs_attr_finish_item(
>                 goto out;
>         }
> 
> +       /* Simulate crash after setflag committed during LARP replace. */
> +       if ((attr->xattri_dela_state == XFS_DAS_NODE_REMOVE_RMT ||
> +            attr->xattri_dela_state == XFS_DAS_NODE_REMOVE_ATTR) &&
> +            (args->op_flags & XFS_DA_OP_LOGGED) &&
> +            !(args->op_flags & XFS_DA_OP_RECOVERY)) {
> +               xfs_force_shutdown(args->dp->i_mount,
> +                                  SHUTDOWN_CORRUPT_INCORE);
> +               error = -EIO;
> +               goto out;
> +       }
> +
>         error = xfs_attr_set_iter(attr);
>         if (!error && attr->xattri_dela_state != XFS_DAS_DONE)
>                 return -EAGAIN;
> 
> >
> > Also, if you apply that patch so that it creates the incomplete attr
> > name, do you end up with a consistent filesystem afterwards?
> 
> No. After applying the patch, the filesystem remains consistent
> after the run. xfs_repair -n does not report any structural
> corruption or incomplete attribute.
> I haven’t done exhaustive testing yet, though.
> 
> >
> > I think xfs_repair could report incomplete attr names instead of
> > clobbering the whole attr fork.  xfs_scrub can fix it, so it's not a big
> > deal to leave incomplete names around ... unless it'll confuse
> > xfs_attr_set?
> 
> I agree. I took a look at your xfs_progs commit
> 11a22e694671c112b3ebfffe879cc148cb8b5494.
> 
> >
> > (Also, do you ever see the xfs_repair in g/753 fail with complaints
> > about a corrupt attr leaf block at block offset 0?  I've seen that once
> > or twice but haven't reproduced it consistently yet...)
> 
> If you're referring to xfs_repair -n corruption errors like:
> 
> Metadata corruption detected at 0x55dc57df7f68,
> xfs_da3_node block 0x10801d0/0x1000
> corrupt block 0 of inode 25165954 attribute fork
> problem with attribute contents in inode 25165954
> would clear attr fork
> 
> Yes, I’ve seen this once as well. However, I haven’t been able
> to reproduce it reliably.

I think this patchset
https://lore.kernel.org/linux-xfs/20260312085800.1213919-1-leo.lilong@huawei.com/

nearly fixes that problem.  I added a small follow-on in
https://lore.kernel.org/linux-xfs/20260316045613.GU1770774@frogsfrogsfrogs/

which seems to have fixed the problem completely, at least if you have
this xfs_repair patch also applied:
https://lore.kernel.org/linux-xfs/20260316225033.GP6069@frogsfrogsfrogs/

--D

> Thanks,
> Ravi
> 
> >
> > --D
> >
> 
>