| Message ID | 1396118619-12771-2-git-send-email-trond.myklebust@primarydata.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Mar 29, 2014 at 02:43:39PM -0400, Trond Myklebust wrote: > RFC5661 obsoletes NFS4ERR_RESTOREFH in favour of NFS4ERR_NOFILEHANDLE. Looks right. Any objection to just making this nfserr_restorefh in the 4.0 case as well? Hard to imagine how that could cause a 4.0 client any problem. --b. > > Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> > --- > fs/nfsd/nfs4proc.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c > index 82189b208af3..eeee4418d44a 100644 > --- a/fs/nfsd/nfs4proc.c > +++ b/fs/nfsd/nfs4proc.c > @@ -536,8 +536,11 @@ static __be32 > nfsd4_restorefh(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, > void *arg) > { > - if (!cstate->save_fh.fh_dentry) > + if (!cstate->save_fh.fh_dentry) { > + if (nfsd4_has_session(cstate)) > + return nfserr_nofilehandle; > return nfserr_restorefh; > + } > > fh_dup2(&cstate->current_fh, &cstate->save_fh); > if (HAS_STATE_ID(cstate, SAVED_STATE_ID_FLAG)) { > -- > 1.9.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mar 29, 2014, at 15:34, J. Bruce Fields <bfields@fieldses.org> wrote: > On Sat, Mar 29, 2014 at 02:43:39PM -0400, Trond Myklebust wrote: >> RFC5661 obsoletes NFS4ERR_RESTOREFH in favour of NFS4ERR_NOFILEHANDLE. > > Looks right. Any objection to just making this nfserr_restorefh in the > 4.0 case as well? Hard to imagine how that could cause a 4.0 client any > problem. You mean make both cases return nfserr_nofilehandle (as per RFC5661), right? So, I agree that most clients should handle that, but the problem is that RFC3530bis does not allow it. > > --b. > >> >> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> >> --- >> fs/nfsd/nfs4proc.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c >> index 82189b208af3..eeee4418d44a 100644 >> --- a/fs/nfsd/nfs4proc.c >> +++ b/fs/nfsd/nfs4proc.c >> @@ -536,8 +536,11 @@ static __be32 >> nfsd4_restorefh(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, >> void *arg) >> { >> - if (!cstate->save_fh.fh_dentry) >> + if (!cstate->save_fh.fh_dentry) { >> + if (nfsd4_has_session(cstate)) >> + return nfserr_nofilehandle; >> return nfserr_restorefh; >> + } >> >> fh_dup2(&cstate->current_fh, &cstate->save_fh); >> if (HAS_STATE_ID(cstate, SAVED_STATE_ID_FLAG)) { >> -- >> 1.9.0 >>
On Mar 29, 2014, at 15:49, Trond Myklebust <trond.myklebust@primarydata.com> wrote: > > On Mar 29, 2014, at 15:34, J. Bruce Fields <bfields@fieldses.org> wrote: > >> On Sat, Mar 29, 2014 at 02:43:39PM -0400, Trond Myklebust wrote: >>> RFC5661 obsoletes NFS4ERR_RESTOREFH in favour of NFS4ERR_NOFILEHANDLE. >> >> Looks right. Any objection to just making this nfserr_restorefh in the >> 4.0 case as well? Hard to imagine how that could cause a 4.0 client any >> problem. > > You mean make both cases return nfserr_nofilehandle (as per RFC5661), right? So, I agree that most clients should handle that, but the problem is that RFC3530bis does not allow it. Either way, this is not a performance critical issue. Any time we get into this situation, it is because the client is utterly screwed up in the first place. The NFS4ERR_STALE_STATEID is the critical one that really needs to be applied...
On Sat, Mar 29, 2014 at 04:01:15PM -0400, Trond Myklebust wrote: > > On Mar 29, 2014, at 15:49, Trond Myklebust <trond.myklebust@primarydata.com> wrote: > > > > > On Mar 29, 2014, at 15:34, J. Bruce Fields <bfields@fieldses.org> wrote: > > > >> On Sat, Mar 29, 2014 at 02:43:39PM -0400, Trond Myklebust wrote: > >>> RFC5661 obsoletes NFS4ERR_RESTOREFH in favour of NFS4ERR_NOFILEHANDLE. > >> > >> Looks right. Any objection to just making this nfserr_restorefh in the > >> 4.0 case as well? Hard to imagine how that could cause a 4.0 client any > >> problem. > > > > You mean make both cases return nfserr_nofilehandle (as per RFC5661), right? So, I agree that most clients should handle that, but the problem is that RFC3530bis does not allow it. > > Either way, this is not a performance critical issue. Any time we get into this situation, it is because the client is utterly screwed up in the first place. Yeah. I don't really care much, applied. > The NFS4ERR_STALE_STATEID is the critical one that really needs to be applied... Already applied, thanks. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c index 82189b208af3..eeee4418d44a 100644 --- a/fs/nfsd/nfs4proc.c +++ b/fs/nfsd/nfs4proc.c @@ -536,8 +536,11 @@ static __be32 nfsd4_restorefh(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, void *arg) { - if (!cstate->save_fh.fh_dentry) + if (!cstate->save_fh.fh_dentry) { + if (nfsd4_has_session(cstate)) + return nfserr_nofilehandle; return nfserr_restorefh; + } fh_dup2(&cstate->current_fh, &cstate->save_fh); if (HAS_STATE_ID(cstate, SAVED_STATE_ID_FLAG)) {
RFC5661 obsoletes NFS4ERR_RESTOREFH in favour of NFS4ERR_NOFILEHANDLE. Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> --- fs/nfsd/nfs4proc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)