On Fri, 4 Dec 2015 09:38:03 +0100 Christoph Hellwig <hch@xxxxxx> 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@xxxxxxxxxxxxxxx> -- 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
