[PATCH 00/16] nfsd patches: bugfixes, deferral, compound processing

[J. Bruce Fields]

These are the patches I have ready for 2.6.20: the usual miscellaneous
bugfixes, then some fixes for the request deferral code, then some
reorganization of the compound processing.  I've also got another set of more
experimental locking patches, to send in later.

A few notes on the deferral problem:

As you know, the knfsd code defers requests for later processing (such as when
waiting for a response from a userland helper daemon) by temporarily "dropping"
the request, storing a copy of it, then revisiting it later.  The client
doesn't normally see this as a dropped request, unless something bad happens
during the deferral or revisit process.  In that case the client never gets a
reply at all.

In the NFSv4 case this is actually a violation of the protocol--we're not
supposed to drop requests without also closing the TCP connection.  And in
general it seems friendlier when possible to return an error to the client.

So I want to remove those silent drops.  For the purposes of NFSv4, I also want
to add some additional state to the deferred request so that we can pick up
compound processing where we left instead of starting over again, eliminating
the possibility of problems caused by processing nonidempotent compound
operations twice.  That will also allow us to remove the special case
deferall/revisit code that we're currently using in idmapd.

For now the following patches just deal with the simplest cases of
silent drops in the deferral code.  (One tricky case remains--the case
where we decide to drop the oldest request in cache_defer_req.  I'm
tempted just to force a revisit of the old request in that case, under
the assumption that when we loop back around and try to defer again
it'll probably result in an error we can return to the client.  But that
seems suboptimal.)

I'm also leaving the saving of extra NFSv4 compound state till later.  I
hope the reorganization of the compound processing will help prepare for
that a little, though.

--b.