Skip to content

Commit 682a7d0

Browse files
jtlaytongregkh
authored andcommitted
nfsd: fix handling of readdir in v4root vs. mount upcall timeout
commit cad8533 upstream. If v4 READDIR operation hits a mountpoint and gets back an error, then it will include that entry in the reply and set RDATTR_ERROR for it to the error. That's fine for "normal" exported filesystems, but on the v4root, we need to be more careful to only expose the existence of dentries that lead to exports. If the mountd upcall times out while checking to see whether a mountpoint on the v4root is exported, then we have no recourse other than to fail the whole operation. Cc: Steve Dickson <steved@redhat.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216777 Reported-by: JianHong Yin <yin-jianhong@163.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1 parent cb42aa7 commit 682a7d0

File tree

1 file changed

+11
-0
lines changed

1 file changed

+11
-0
lines changed

fs/nfsd/nfs4xdr.c

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3514,6 +3514,17 @@ nfsd4_encode_dirent(void *ccdv, const char *name, int namlen,
35143514
case nfserr_noent:
35153515
xdr_truncate_encode(xdr, start_offset);
35163516
goto skip_entry;
3517+
case nfserr_jukebox:
3518+
/*
3519+
* The pseudoroot should only display dentries that lead to
3520+
* exports. If we get EJUKEBOX here, then we can't tell whether
3521+
* this entry should be included. Just fail the whole READDIR
3522+
* with NFS4ERR_DELAY in that case, and hope that the situation
3523+
* will resolve itself by the client's next attempt.
3524+
*/
3525+
if (cd->rd_fhp->fh_export->ex_flags & NFSEXP_V4ROOT)
3526+
goto fail;
3527+
fallthrough;
35173528
default:
35183529
/*
35193530
* If the client requested the RDATTR_ERROR attribute,

0 commit comments

Comments
 (0)