Possible fixes for 2.6.32 stable

Possible fixes for 2.6.32 stable

[Chuck Lever]

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.


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

>From 2.6.36: 669502ff

These apply cleanly in this order to 2.6.32.  With these commits applied, our UEK NFS clients can reconnect on the first attempt to an NFS server after a TCP connection drop.


-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: Possible fixes for 2.6.32 stable

[Greg KH]

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