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

[Jeff Layton <jlayton@poochiereds.net>]

On Sat, 5 Dec 2015 13:02:22 +0100
Christoph Hellwig <hch@lst.de> wrote:

> On Fri, Dec 04, 2015 at 03:51:10PM -0500, Jeff Layton wrote:
> > > 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...
> 
> If we start allowing layoutgets before the whole range has been
> returned there is a great chance for livelocks, yes.  But I don't think
> we should allow layoutgets to proceed before that.

Maybe I didn't describe it well enough. I think you can still end up
looping even if you don't allow LAYOUTGETs before the entire range is
returned.

If we treat NFS4_OK and NFS4ERR_DELAY equivalently, then we're
expecting the client to eventually return NFS4ERR_NOMATCHING_LAYOUT (or
a different error) to break the cycle of retransmissions. But, HZ/100
is enough time for the client to return a layout and request a new one.
We may never see that error -- only a continual cycle of
CB_LAYOUTRECALL/LAYOUTRETURN/LAYOUTGET.

I think we need a more reliable way to break that cycle so we don't end
up looping like that. We should either cancel any active callbacks
before reallowing LAYOUTGETs, or move the timeout handling outside of
the RPC state machine (like Bruce was suggesting).

-- 
Jeff Layton <jlayton@poochiereds.net>