Re: [PATCH v2] nfsd: map EBUSY to NFS4ERR_ACCESS for all operations

[Chuck Lever <chuck.lever@oracle.com>]

Please send patches To: the NFSD reviewers listed in MAINTAINERS and
Cc: linux-nfs and others. Thanks!


On 1/21/25 5:39 AM, Amir Goldstein wrote:
> Commit 466e16f0920f3 ("nfsd: check for EBUSY from vfs_rmdir/vfs_unink.")
> mapped EBUSY host error from rmdir/unlink operation to avoid unknown
> error server warning.

> The same reason that casued the reported EBUSY on rmdir() (dir is a
> local mount point in some other bind mount) could also cause EBUSY on
> rename and some filesystems (e.g. FUSE) can return EBUSY on other
> operations like open().
> 
> Therefore, to avoid unknown error warning in server, we need to map
> EBUSY for all operations.
> 
> The original fix mapped EBUSY to NFS4ERR_FILE_OPEN in v4 server and
> to NFS4ERR_ACCESS in v2/v3 server.
> 
> During the discussion on this issue, Trond claimed that the mapping
> made from EBUSY to NFS4ERR_FILE_OPEN was incorrect according to the
> protocol spec and specifically, NFS4ERR_FILE_OPEN is not expected
> for directories.

NFS4ERR_FILE_OPEN might be incorrect when removing certain types of
file system objects. Here's what I find in RFC 8881 Section 18.25.4:

 > If a file has an outstanding OPEN and this prevents the removal of the
 > file's directory entry, the error NFS4ERR_FILE_OPEN is returned.

It's not normative, but it does suggest that any object that cannot be
associated with an OPEN state ID should never cause REMOVE to return
NFS4ERR_FILE_OPEN.


> To keep things simple and consistent and avoid the server warning,
> map EBUSY to NFS4ERR_ACCESS for all operations in all protocol versions.

Generally a "one size fits all" mapping for these status codes is
not going to cut it. That's why we have nfsd3_map_status() and
nfsd_map_status() -- the set of permitted status codes for each
operation is different for each NFS version.

NFSv3 has REMOVE and RMDIR. You can't pass a directory to NFSv3 REMOVE.

NFSv4 has only REMOVE, and it removes the directory entry for the
object no matter its type. The set of failure modes is different for
this operation compared to NFSv3 REMOVE.

Adding a specific mapping for -EBUSY in nfserrno() is going to have
unintended consequences for any VFS call NFSD might make that returns
-EBUSY.

I think I prefer that the NFSv4 cases be dealt with in nfsd4_remove(),
nfsd4_rename(), and nfsd4_link(), and that -EBUSY should continue to
trigger a warning.


> Note that the mapping of NFS4ERR_FILE_OPEN to NFSERR_ACCESS in
> nfsd3_map_status() and nfsd_map_status() remains for possible future
> return of NFS4ERR_FILE_OPEN in a more specific use case (e.g. an unlink
> of a sillyrenamed non-dir).
> 
> Fixes: 466e16f0920f3 ("nfsd: check for EBUSY from vfs_rmdir/vfs_unink.")
> Link: https://lore.kernel.org/linux-nfs/20250120172016.397916-1-amir73il@gmail.com/
> Cc: Trond Myklebust <trondmy@hammerspace.com>
> Cc: NeilBrown <neilb@suse.de>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>   fs/nfsd/vfs.c | 10 ++--------
>   1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 29cb7b812d713..290c7db8a6180 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -69,6 +69,7 @@ nfserrno (int errno)
>   		{ nfserr_fbig, -E2BIG },
>   		{ nfserr_stale, -EBADF },
>   		{ nfserr_acces, -EACCES },
> +		{ nfserr_acces, -EBUSY},
>   		{ nfserr_exist, -EEXIST },
>   		{ nfserr_xdev, -EXDEV },
>   		{ nfserr_mlink, -EMLINK },

> @@ -2006,14 +2007,7 @@ nfsd_unlink(struct svc_rqst *rqstp, struct svc_fh *fhp, int type,
>   out_drop_write:
>   	fh_drop_write(fhp);
>   out_nfserr:
> -	if (host_err == -EBUSY) {
> -		/* name is mounted-on. There is no perfect
> -		 * error status.
> -		 */
> -		err = nfserr_file_open;
> -	} else {
> -		err = nfserrno(host_err);
> -	}
> +	err = nfserrno(host_err);
>   out:
>   	return err;
>   out_unlock:


-- 
Chuck Lever