Re: [PATCH 2/6] xfs: don't stash removename operations with unknown ftype

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

On Tue, Aug 25, 2026 at 08:28:00AM +0200, Christoph Hellwig wrote:
> On Mon, Aug 24, 2026 at 10:34:54PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > LOLLM notices that the behavior of xrep_dir_replay_update changes based
> > on the ftype recorded in the stashed removename information.  It also
> > notices that the unlink iops sometimes set that ftype to FT_UNKNOWN
> > because the regular directory tree update code paths don't need to know
> > the ftype of the child.
> > 
> > Unfortunately, this results in incorrect link counts, which eventually
> > trips link count errors in later phases of xfs_scrub, or in xfs_repair.
> > Fix this.
> 
> Fix what?
> 
> > @@ -1381,9 +1381,24 @@ xrep_dir_live_update(
> >  		if (p->delta > 0)
> >  			error = xrep_dir_stash_createname(rd, p->name,
> >  					I_INO(p->ip));
> > -		else
> > -			error = xrep_dir_stash_removename(rd, p->name,
> > +		else {
> > +			/*
> > +			 * xfs_dentry_to_name in unlink or rename-exchange can
> > +			 * pass us names with ftype FT_UNKNOWN, but we really
> > +			 * must know the ftype of the child that is being
> > +			 * removed so that we can do nlink updates correctly
> > +			 * without holding inode references.
> > +			 */
> > +			struct xfs_name	name = {
> > +				.name	= p->name->name,
> > +				.len	= p->name->len,
> > +				.type	= xfs_mode_to_ftype(
> > +						VFS_IC(p->ip)->i_mode),
> > +			};
> 
> .. fix up the xfs_name to always have the correct type is I guess what
> the commit log should say.

I'll expand that last sentence to read:
"Fix this by creating a second xfs_name with the type set correctly."

> With that:
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Thanks!

--D