ACK w/cmnts: [Precise][PATCH 0/4] nfs: Kernel Oops on nfs_have_delegation

[Luis Henriques]

On Thu, Apr 19, 2012 at 03:00:42PM +0200, Stefan Bader wrote:
> On 19.04.2012 11:44, Luis Henriques wrote:
> > BugLink: http://bugs.launchpad.net/bugs/974664
> > 
> > == Precise SRU Justification ==
> > 
> > This bug is preventing users from using NFS clients on Precise.
> > Several users have reported the issue, which has been already fixed
> > upstreams but did not made it into stable yet.
> > 
> > == Fix ==
> > 
> > There are four commits that are relevant to fix this issue.  From
> > mainline kernel:
> >  - 14977489ffdb80d4caf5a184ba41b23b02fbacd9 (cherry-pick)
> 
> Beside the additional check for inode not being NULL the other changes seem
> purely reordering without changing the effective handling. Ok.
> 
> >  - 96dcadc2fdd111dca90d559f189a30c65394451a (backported)
> 
> Adding a rate-limit. No worries.
> 
> > From linux-nfs git tree
> > (git://git.linux-nfs.org/projects/trondmy/linux-nfs.git):
> >  - 487790f27df9bb27d3400486bd021dd59edc7589 (cherry-pick)
> 
> If this is needed for Precise, maybe checking with Trond would be good, as he
> seems to think only 3.3.1+ requires this. It sounds reasonable.
> 
> >  - 5de4815015e550bdd33f39650554325540356f0c (cherry-pick)
> 
> The reasoning sounds ok. The code is... well at least I find it a bit nebulous.
> I assume only read+unlock and write+unlock combinations are possible and in
> those cases it is desired to not check for the filemode...
> 
> Given the seriousness of the bug, positive feedback I think it is acceptable to
> pull the patches in. Though only #1 is required to fix the crash and #2 stops
> the message flooding. #3 and #4 fix the flock functionality problems and
> strictly those would be less important. But while touching things anyway...

Right, so #1 actually fixes the original problem being reported.  However,
#2 will just reduce the messages flooding, but there will still be a huge
amount of them (according to reporters).  So, patches #3 and #4 are
actually required to fix the whole thing.
 
> Still it would be good if you could get in touch with Trond, first because #1
> has not been marked stable and the NULL pointer check is important. Second as it
> seems at least #3 should applied further back. And following that #4 (but that
> is generally cc'ed stable). #2 seems at bit optional with #3 and #4...imo

Ok, I'll ping Trond about this.  I saw patches marked to stable but didn't
noticed the ">= 3.3.1" part.  Also refer that patch #1 should go into
stable as well.

Cheers,
--
Luis

>
> -Stefan
> > 
> > == Impact ==
> > 
> > There are several users reporting the same issue when running NFS
> > clients on Precise.  Other reports have also been found with the same
> > issue:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=811138
> > 
> > == Test Case ==
> > 
> > According to one of the bug reporters:
> > 
> > "Logging into a 12.04 client system with autofs5, LDAP, kerberos authenticated
> > nfs4 mounts. However this is to a server which is running 10.04 (contrary to #4
> > it seems) In my case the triggering process is gnome-keyring-d."
> > 
> > Trond Myklebust (3):
> >   NFSv4: Minor cleanups for nfs4_handle_exception and
> >     nfs4_async_handle_error
> >   NFSv4: Ensure that the LOCK code sets exception->inode
> >   NFSv4: Ensure that we check lock exclusive/shared type against open
> >     modes
> > 
> > William Dauchy (1):
> >   NFSv4: Rate limit the state manager for lock reclaim warning messages
> > 
> >  fs/nfs/nfs4proc.c  |   33 ++++++++++++++++++++++++++-------
> >  fs/nfs/nfs4state.c |    5 +++--
> >  2 files changed, 29 insertions(+), 9 deletions(-)
> > 
> 
>