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

[Christoph Hellwig <hch@lst.de>]

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.

With that:

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