On Tue, Sep 01, 2015 at 09:18:42AM -0400, Jeff Layton wrote: > On Mon, 31 Aug 2015 12:06:41 -0400 > Andrew Elble <aweits@xxxxxxx> wrote: > > > We have observed the server sending recalls for delegation stateids > > that have already been successfully returned. Change > > nfsd4_cb_recall_done() to return success if the client has returned > > the delegation. While this does not completely eliminate the sending > > of recalls for delegations that have already been returned, this > > does prevent unnecessarily declaring the callback path to be down. > > > > Reported-by: Eric Meddaugh <etmsys@xxxxxxx> > > Signed-off-by: Andrew Elble <aweits@xxxxxxx> > > --- > > fs/nfsd/nfs4state.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c > > index de45c2de1668..ac235a7470e3 100644 > > --- a/fs/nfsd/nfs4state.c > > +++ b/fs/nfsd/nfs4state.c > > @@ -3509,6 +3509,9 @@ static int nfsd4_cb_recall_done(struct nfsd4_callback *cb, > > { > > struct nfs4_delegation *dp = cb_to_delegation(cb); > > > > + if (dp->dl_stid.sc_type == NFS4_CLOSED_DELEG_STID) > > + return 1; > > + > > switch (task->tk_status) { > > case 0: > > return 1; > > Yeah, there will always be some potential for a CB_RECALL/DELEGRETURN > race since the former is driven by the server and the latter by the > client. > > What error are you usually getting back from the client when you see > this happen? NFS4ERR_BAD_STATEID? If so, then maybe we should confine > this check to that error case? > > OTOH, maybe there's no harm in just ignoring the error if the > delegation is already returned... > > Acked-by: Jeff Layton <jlayton@xxxxxxxxxxxxxxx> Agreed, applying--thanks.--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