From: Amir Goldstein <amir73il@gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
Trond Myklebust <trondmy@hammerspace.com>,
NeilBrown <neilb@suse.de>
Subject: [PATCH v2] nfsd: map EBUSY to NFS4ERR_ACCESS for all operations
Date: Tue, 21 Jan 2025 11:39:54 +0100 [thread overview]
Message-ID: <20250121103954.415462-1-amir73il@gmail.com> (raw)
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.
To keep things simple and consistent and avoid the server warning,
map EBUSY to NFS4ERR_ACCESS for all operations in all protocol versions.
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:
--
2.34.1
next reply other threads:[~2025-01-21 10:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-21 10:39 Amir Goldstein [this message]
2025-01-21 12:21 ` [PATCH v2] nfsd: map EBUSY to NFS4ERR_ACCESS for all operations Jeff Layton
2025-01-21 19:45 ` Chuck Lever
2025-01-21 21:44 ` Amir Goldstein
2025-01-21 22:59 ` NeilBrown
2025-01-22 9:05 ` Amir Goldstein
2025-01-22 15:04 ` Chuck Lever
2025-01-22 15:29 ` Amir Goldstein
2025-01-22 16:50 ` Chuck Lever
2025-01-22 18:53 ` Amir Goldstein
2025-01-22 19:20 ` Chuck Lever
2025-01-22 20:11 ` Amir Goldstein
2025-01-23 14:59 ` Chuck Lever
2025-01-23 15:29 ` Amir Goldstein
2025-01-23 17:37 ` Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250121103954.415462-1-amir73il@gmail.com \
--to=amir73il@gmail.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=trondmy@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox