summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/lists.py
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2025-01-27 00:50:18 +0300
committerChuck Lever <chuck.lever@oracle.com>2025-03-10 16:10:56 +0300
commit370345b4bd184a49ac68d6591801e5e3605b355a (patch)
treebcf6b0aa3a0080e8a693a1052d492bf6dedb66a5 /scripts/gdb/linux/lists.py
parentd7d8e3169b56e7696559a2427c922c0d55debcec (diff)
downloadlinux-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