]> Gitweb @ Texas Instruments - Open Source Git Repositories - git.TI.com/gitweb - keystone-linux/linux.git/commit
NFSv4: nfs4_state_manager() vs. nfs_server_remove_lists()
authorSteve Dickson <steved@redhat.com>
Thu, 18 Sep 2014 13:13:17 +0000 (09:13 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 5 Oct 2014 21:54:10 +0000 (14:54 -0700)
commit648d333d7d845d4364d0fab9d31ebb48e4641bfb
tree7a9975bf2705d7bc8d98c3cdde07ecfb4e4cee4d
parent47415d5452b8945bfbe7e2adb3fa15658b3c3d21
NFSv4: nfs4_state_manager() vs. nfs_server_remove_lists()

commit 080af20cc945d110f9912d01cf6b66f94a375b8d upstream.

There is a race between nfs4_state_manager() and
nfs_server_remove_lists() that happens during a nfsv3 mount.

The v3 mount notices there is already a supper block so
nfs_server_remove_lists() called which uses the nfs_client_lock
spin lock to synchronize access to the client list.

At the same time nfs4_state_manager() is running through
the client list looking for work to do, using the same
lock. When nfs4_state_manager() wins the race to the
list, a v3 client pointer is found and not ignored
properly which causes the panic.

Moving some protocol checks before the state checking
avoids the panic.

Signed-off-by: Steve Dickson <steved@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/nfs/nfs4client.c