diff options
author | Chuck Lever <chuck.lever@oracle.com> | 2025-01-27 00:50:18 +0300 |
---|---|---|
committer | Chuck Lever <chuck.lever@oracle.com> | 2025-03-10 16:10:56 +0300 |
commit | 370345b4bd184a49ac68d6591801e5e3605b355a (patch) | |
tree | bcf6b0aa3a0080e8a693a1052d492bf6dedb66a5 /scripts/gdb/linux/lists.py | |
parent | d7d8e3169b56e7696559a2427c922c0d55debcec (diff) | |
download | linux-370345b4bd184a49ac68d6591801e5e3605b355a.tar.xz |
NFSD: Never return NFS4ERR_FILE_OPEN when removing a directory
RFC 8881 Section 18.25.4 paragraph 5 tells us that the server
should return NFS4ERR_FILE_OPEN only if the target object is an
opened file. This suggests that returning this status when removing
a directory will confuse NFS clients.
This is a version-specific issue; nfsd_proc_remove/rmdir() and
nfsd3_proc_remove/rmdir() already return nfserr_access as
appropriate.
Unfortunately there is no quick way for nfsd4_remove() to determine
whether the target object is a file or not, so the check is done in
in nfsd_unlink() for now.
Reported-by: Trond Myklebust <trondmy@hammerspace.com>
Fixes: 466e16f0920f ("nfsd: check for EBUSY from vfs_rmdir/vfs_unink.")
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to 'scripts/gdb/linux/lists.py')
0 files changed, 0 insertions, 0 deletions