Re: [PATCH RFC] nfsd: serialize layout stateid morphing operations

[Jeff Layton <jlayton@poochiereds.net>]

On Fri, 4 Dec 2015 09:38:03 +0100
Christoph Hellwig <hch@lst.de> wrote:

> On Thu, Dec 03, 2015 at 05:08:50PM -0500, J. Bruce Fields wrote:
> > OK, so if I understand right, the current code is letting the rpc state
> > machine drive the whole thing, and your proposal is that the rpc task
> > lasts until the client either responds NFS4ERR_NOMATCHING_LAYOUT or we
> > just run out of time.  (NOMATCHING_LAYOUT being the one response that
> > isn't either "try again" or "OK I'll get to it soon").
> 
> Yes (except fatal errors would end the rpc state machine).
> 
> > I understand why that would work, and that handling anything other than
> > the NOMATCHING_LAYOUT case is a lower priority for now, but this
> > approach worries me.
> > 
> > Is there a reason we can't do as in the delegation case, and track the
> > revocation timeout separately from the callback rpc?
> 
> There is no reason not to do it, except for the significant effort
> to implement it a well as a synthetic test case to actually reproduce
> the behavior we want to handle.

Could you end up livelocking here? Suppose you issue the callback and
the client returns success. He then returns the layout and gets a new
one just before the delay timer pops. We then end up recalling _that_
layout...rinse, repeat...

I'm not opposed to using the state machine to drive this, but I think
I'd like to see some mechanism to cancel any callbacks that are still
in limbo, before the server starts handing out layouts again for the
file.

-- 
Jeff Layton <jlayton@poochiereds.net>