Re: [PATCH v2 02/14] nfs: correctly handle NFS4ERR_WRONG_TYPE from v4 OPEN request

[Jeff Layton <jlayton@kernel.org>]

Some agentic review found a potential issue here:

> diff --git a/fs/nfs_common/common.c b/fs/nfs_common/common.c
> index 0778743ae2c2..24add750c8d5 100644
> --- a/fs/nfs_common/common.c
> +++ b/fs/nfs_common/common.c
> @@ -102,6 +102,7 @@ static const struct {
>  	{ NFS4ERR_BADTYPE,	-EBADTYPE	},
>  	{ NFS4ERR_SYMLINK,	-ELOOP		},
>  	{ NFS4ERR_DEADLOCK,	-EDEADLK	},
> +	{ NFS4ERR_WRONG_TYPE,	-EFTYPE		},
>  };

[ ... ]

The new mapping also changes what filelayout_async_handle_error() in
fs/nfs/filelayout/filelayout.c sees for this status. That function
switches on the decoded task status, which mixes mapped errnos with raw
NFSv4 codes:

fs/nfs/filelayout/filelayout.c:filelayout_async_handle_error() {
	...
	case -ESTALE:           /* mapped NFS4ERR_STALE */
	case -EBADHANDLE:       /* mapped NFS4ERR_BADHANDLE */
	case -EISDIR:           /* mapped NFS4ERR_ISDIR */
	case -NFS4ERR_FHEXPIRED:
	case -NFS4ERR_WRONG_TYPE:
		...
		pnfs_destroy_layout(NFS_I(inode));
		rpc_wake_up(&tbl->slot_tbl_waitq);
		goto reset;
	...
	default:
reset:
		return -NFS4ERR_RESET_TO_MDS;
}

Before this commit a data server returning WRONG_TYPE arrived as
-NFS4ERR_WRONG_TYPE and took the layout-invalidating path above. With
the new mapping it arrives as -EFTYPE, which matches no case and falls
into default, so the I/O is still retried through the MDS but the
layout is no longer destroyed and the slot waitqueue is not woken.

Should the "Invalidate Layout errors" group gain a case for -EFTYPE
alongside the mapped -EISDIR case, the way the other mapped codes are
handled there?

-- 
Jeff Layton <jlayton@kernel.org>