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

[Stefan Bader]

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

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

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20120419/e5ed53c8/attachment.sig>