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:52:15 +0000 (14:52 -0700)
commitc347c76f3678a0b6e23b2a90aa538126475e19c8
tree3a7cd49cd03d7dcf8b276a66fb513354535abd69
parent433ec1a32c7380567c38226a6c490fd899339017
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