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