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

[Neil Brown]

On Friday December 1, bfields at fieldses.org wrote:
> 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.
> 

Thanks.  Looks good.  I did make a few cosmetic changes though.  I
removed a few trailing white spaces and wrapped a whole lot of >80 char
lines.

I also changed
	if (rv == -EAGAIN)
		if (cache_defer_req(rqstp, h))
			rv = -ETIMEDOUT;
to
	if (rv == -EAGAIN)
		if (cache_defer_req(rqstp, h) < 0)
			rv = -ETIMEDOUT;

so it is more obviously correct (to me).

I also note that if ip_map_lookup returns ETIMEDOUT we still drop the
request.... we aren't really in a position to return and NFS error at
that point.
This should happen very rarely as the ipm is cached per TCP connection,
but it is still possible at first connect and if the cache gets
updated.  I presume we should break the TCP connection in that
very-rare case ??


> 
> 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.)

Do we need "optimal" in this case.  Maybe "obvious if slow" is more
appropriate of rare edge cases such as this?

Thanks,
NeilBrown