Re: [stable] nfsd changes for 2.6.34

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Mar 30, 2010 at 01:03:20PM -0700, Greg KH wrote:
> On Tue, Mar 30, 2010 at 10:40:54AM -0400, J. Bruce Fields wrote:
> > On Mon, Mar 29, 2010 at 11:24:43AM -0700, Greg KH wrote:
> > > On Wed, Mar 24, 2010 at 10:24:14AM -0400, J. Bruce Fields wrote:
> > > > On Sat, Mar 06, 2010 at 12:52:12PM -0500, bfields wrote:
> > > > > Please pull the following nfsd changes from the 'nfsd' branch at:
> > > > > 
> > > > >   git://linux-nfs.org/~bfields/linux.git for-2.6.34 nfsd
> > > > > 
> > > > > This is an unusually quiet cycle for the NFS server--bugfixes, some IPv6
> > > > > progress, and one new export operation to improve sync performance.
> > > > > 
> > > > > One exception to the 'mostly quiet' statement was a regression in the
> > > > > rpc code which hit a lot of people: enormous thanks to Neil for tracking
> > > > > that down.
> > > > 
> > > > However, I forgot to Cc stable on all of those.  Stable people, could
> > > > you also take the following three commits?:
> > > > 
> > > > 	f5822754ea006563e1bf0a1f43faaad49c0d8bb2 Revert "sunrpc: fix
> > > > 	peername failed on closed listener"
> > > > 	1b644b6e6f6160ae35ce4b52c2ca89ed3e356e18 Revert "sunrpc: move
> > > > 	the close processing after do recvfrom method"
> > > > 	301e99ce4a2f42a317129230fd42e6cd874c64b0 nfsd: ensure sockets
> > > > 	are closed on error
> > > > 
> > > > Let me know if you need more information.
> > > 
> > > I've queued all of these up for the .33 -stable tree.  If any of them
> > > need to go into .32 (maybe that last one?), please let me know.
> > 
> > Thanks; .32 needs all three of those.
> 
> Ok, care to backport them and send them to stable@kernel.org?  They
> don't all apply cleanly from what I can see.

Huh.  I just checked out 2.6.32.10 and tried applying the patches a
couple different ways, and the worst I got was stuff like:

	patching file net/sunrpc/svc_xprt.c
	Hunk #1 succeeded at 711 (offset 5 lines).

Is that enough that you don't consider them clean?

In any case, I'll follow up with patches generated against 2.6.32.10.

--b.