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>
This commit is contained in:
parent
4b8449af75
commit
f7b8066f9f
@ -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);
|
||||
|
Loading…
Reference in New Issue
Block a user