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)
committerJiri Slaby <jslaby@suse.cz>
Mon, 13 Oct 2014 13:41:05 +0000 (15:41 +0200)
commitc6365a41b6f7fb99458f9b6a4ea76f0f67b345cd
tree01f38d364664d6bb1cc974c58f565eae4a3e5e42
parentab100e044866897de87b9feb5ac819c1ca2f1006
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: Jiri Slaby <jslaby@suse.cz>
fs/nfs/nfs4client.c