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
