knfsd: don't bother mapping putrootfh enoent to eperm

Neither EPERM and ENOENT map to valid errors for PUTROOTFH according to
rfc 3530, and, if anything, ENOENT is likely to be slightly more
informative; so don't bother mapping ENOENT to EPERM.  (Probably this
was originally done because one likely cause was that there is an fsid=0
export but that it isn't permitted to this particular client.  Now that
we allow WRONGSEC returns, this is somewhat less likely.)

In the long term we should work to make this situation less likely,
perhaps by turning off nfsv4 service entirely in the absence of the
pseudofs root, or constructing a pseudofilesystem root ourselves in the
kernel as necessary.

Thanks to Benny Halevy <bhalevy@panasas.com> for pointing out this
problem.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Benny Halevy <bhalevy@panasas.com>

diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index cbbc594ef592c37ea96779c9ba1e9ee37ddefec4..79b4bf8129602b9ebbbec979960d614e90b7185b 100644 (file)
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -1357,8 +1357,6 @@ exp_pseudoroot(struct svc_rqst *rqstp, struct svc_fh *fhp)
        mk_fsid(FSID_NUM, fsidv, 0, 0, 0, NULL);
 
        exp = rqst_exp_find(rqstp, FSID_NUM, fsidv);
-       if (PTR_ERR(exp) == -ENOENT)
-               return nfserr_perm;
        if (IS_ERR(exp))
                return nfserrno(PTR_ERR(exp));
        rv = fh_compose(fhp, exp, exp->ex_dentry, NULL);