Kernel crashes when repeatedly trying to mount nfs share that is failing

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
(Created page with "== About == * Kernel version: 2.6.32, 2.6.37-rc3 * [https://bugzilla.kernel.org/show_bug.cgi?id=24302 Bug 24302] * Reported by: Stefan Bader (December 3, 2010) * Closed by: Flori...")
 
(2 intermediate revisions not shown)
Line 3: Line 3:
* [https://bugzilla.kernel.org/show_bug.cgi?id=24302 Bug 24302]
* [https://bugzilla.kernel.org/show_bug.cgi?id=24302 Bug 24302]
* Reported by: Stefan Bader (December 3, 2010)
* Reported by: Stefan Bader (December 3, 2010)
 +
* Fixed by: Chuck Lever (December 10, 2010)
* Closed by: Florian Mickler (December 24, 2011)
* Closed by: Florian Mickler (December 24, 2011)
Line 21: Line 22:
* The following is done in a loop as the crash sometimes takes longer than other times:
* The following is done in a loop as the crash sometimes takes longer than other times:
<pre>while true; do
<pre>while true; do
-
    ls foo/
+
ls foo/
-
    sleep 1
+
sleep 1
done</pre>
done</pre>
* It seems to take longer on the newest kernel, but eventually there will be a panic.
* It seems to take longer on the newest kernel, but eventually there will be a panic.
 +
 +
 +
== Resolution ==
 +
* This problem was fixed by commit [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5b362ac3799ff4225c40935500f520cad4d7ed66 5b362ac3799ff4225c40935500f520cad4d7ed66]
 +
<pre>
 +
commit 5b362ac3799ff4225c40935500f520cad4d7ed66
 +
Author: Chuck Lever <chuck.lever@oracle.com>
 +
Date:  Fri Dec 10 12:31:14 2010 -0500
 +
 +
    NFS: Fix panic after nfs_umount()
 +
   
 +
    After a few unsuccessful NFS mount attempts in which the client and
 +
    server cannot agree on an authentication flavor both support, the
 +
    client panics.  nfs_umount() is invoked in the kernel in this case.
 +
   
 +
    Turns out nfs_umount()'s UMNT RPC invocation causes the RPC client to
 +
    write off the end of the rpc_clnt's iostat array.  This is because the
 +
    mount client's nrprocs field is initialized with the count of defined
 +
    procedures (two: MNT and UMNT), rather than the size of the client's
 +
    proc array (four).
 +
   
 +
    The fix is to use the same initialization technique used by most other
 +
    upper layer clients in the kernel.
 +
   
 +
    Introduced by commit 0b524123, which failed to update nrprocs when
 +
    support was added for UMNT in the kernel.
 +
   
 +
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=24302
 +
    BugLink: http://bugs.launchpad.net/bugs/683938
 +
   
 +
    Reported-by: Stefan Bader <stefan.bader@canonical.com>
 +
    Tested-by: Stefan Bader <stefan.bader@canonical.com>
 +
    Cc: stable@kernel.org # >= 2.6.32
 +
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
 +
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
 +
</pre>

Latest revision as of 19:16, 29 July 2011

About

  • Kernel version: 2.6.32, 2.6.37-rc3
  • Bug 24302
  • Reported by: Stefan Bader (December 3, 2010)
  • Fixed by: Chuck Lever (December 10, 2010)
  • Closed by: Florian Mickler (December 24, 2011)


How to reproduce

  • ARCH: x86_64 (not tested on i386)
  • On the server side, configure an export that will be denied to mount (used sec=krb5 as that gives a permission denied for me)
  • server /etc/exports
/foo *(rw,krb5)
  • On the client side, autofs gets configured to try to automount server:/foo
  • client /etc/auto.master
/auto /etc/auto.auto
  • client /etc/auto.auto
foo -tcp server:/foo
  • Stop the autofs service and start the automounter in the foreground (automount -d -f) to see the permission denied message.
  • Create a symlink pointing to the autofs:
ln -s /auto/foo foo
  • The following is done in a loop as the crash sometimes takes longer than other times:
while true; do
	ls foo/
	sleep 1
done
  • It seems to take longer on the newest kernel, but eventually there will be a panic.


Resolution

commit 5b362ac3799ff4225c40935500f520cad4d7ed66
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Fri Dec 10 12:31:14 2010 -0500

    NFS: Fix panic after nfs_umount()
    
    After a few unsuccessful NFS mount attempts in which the client and
    server cannot agree on an authentication flavor both support, the
    client panics.  nfs_umount() is invoked in the kernel in this case.
    
    Turns out nfs_umount()'s UMNT RPC invocation causes the RPC client to
    write off the end of the rpc_clnt's iostat array.  This is because the
    mount client's nrprocs field is initialized with the count of defined
    procedures (two: MNT and UMNT), rather than the size of the client's
    proc array (four).
    
    The fix is to use the same initialization technique used by most other
    upper layer clients in the kernel.
    
    Introduced by commit 0b524123, which failed to update nrprocs when
    support was added for UMNT in the kernel.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=24302
    BugLink: http://bugs.launchpad.net/bugs/683938
    
    Reported-by: Stefan Bader <stefan.bader@canonical.com>
    Tested-by: Stefan Bader <stefan.bader@canonical.com>
    Cc: stable@kernel.org # >= 2.6.32
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Personal tools