Re: Possible fixes for 2.6.32 stable

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Feb 06, 2012 at 02:11:37PM -0500, Chuck Lever wrote:
> Hi-
> 
> Oracle's UEK kernel is within a few dozen commits of 2.6.32 stable.
> We recently discovered two critical problems with the NFS client in
> UEK that have upstream fixes that can be back ported.  I'm notifying
> you as a courtesy because these problems were reproduced in
> 2.6.32-stable, and the fixes are simple back ports you may wish to
> apply.
> 
> 
> The first issue: The 2.6.32 NFS client fails to perform NFSv4 state
> recovery after a server reboot if an NFS server returns
> NFS4ERR_NO_GRACE, and then blocks state recovery because its grace
> period has not expired.  Because the client fails to perform state
> recovery, it continues to use stale NFSv4 state tokens, which causes,
> among other symptoms, an infinite loop with the server.  The fixes for
> this are:
> 
> From 2.6.33: e345e88a, 4f7cdf18, c8b7ae3d, a9ed2e25
> 
> From 2.6.36: b0ed9dbc
> 
> These cleanly apply in that order to 2.6.32.  With these commits
> applied, our UEK NFS clients are able to perform NFSv4 state recovery
> correctly when an NFS server returns NFS4ERR_NO_GRACE.

These all look sane, I've queued them up now.

> The second issue: After a RPC over TCP connection is dropped, the
> 2.6.32 RPC client reconnects then immediately drops a new TCP
> connection, in a loop.  The client's NFS mount point becomes unusable.
> The fixes for this are:
> 
> From 2.6.34: 5fe46e9d

This applied fine.

> From 2.6.36: 669502ff

This one was contained in 2.6.32.40 (May 2011), so you you are still
needing it, please let me know what is wrong with the existing tree.

thanks,

greg k-h