On Fri, Aug 12, 2011 at 11:52:05AM -0400, Trond Myklebust wrote: > On Thu, 2011-08-11 at 18:29 -0700, Boaz Harrosh wrote: > > With this patch I'm back to the previous behavior. That is > > wait your grace period then continue. > > > > --- > > NFSD: Remove a wrong check in nfs4_open > > > > We are already doing the proper grace period checking > > farther down in nfs4_open. This check was just checking > > nothing and was totally unrelated to the comment about > > "RECLAIM_COMPLETE". It was a bug because if an open was > > coming before the grace period end, it would then never > > pass the condition of not being cl_firststate. > > > > Boaz > > > > --- > > @@ -295,15 +295,6 @@ nfsd4_open(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, > > if (open->op_create && open->op_claim_type != NFS4_OPEN_CLAIM_NULL) > > return nfserr_inval; > > > > - /* > > - * RFC5661 18.51.3 > > - * Before RECLAIM_COMPLETE done, server should deny new lock > > - */ > > - if (nfsd4_has_session(cstate) && > > - !cstate->session->se_client->cl_firststate && > > - open->op_claim_type != NFS4_OPEN_CLAIM_PREVIOUS) > > - return nfserr_grace; > > - > > BTW: restricting opens to CLAIM_PREVIOUS only during the grace period > seems wrong. > > If I have already reclaimed my delegation, then why shouldn't I be able > to do a CLAIM_DELEGATE_CUR and/or CLAIM_DELEG_CUR_FH open? It is not as > if those can ever cause a lock that will conflict with some other > client's lock reclaims. I was assuming the client had to send a reclaim_complete before it could do that, but... I think you're right, those must fall under the "reclaim operations" that a client is allowed to do before the reclaim_complete. I need to look at rfc 5661 10.2.1--I don't think we have that stuff right at all. Argh. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
