nfsd: Ensure we don't recognise lock stateids after freeing them
authorTrond Myklebust <trond.myklebust@primarydata.com>
Fri, 3 Nov 2017 12:00:13 +0000 (08:00 -0400)
committerJ. Bruce Fields <bfields@redhat.com>
Mon, 27 Nov 2017 21:45:10 +0000 (16:45 -0500)
commit659aefb68eca28ba9aa482a9fc64de107332e256
treea8183d2a3c27c9f74a21051015362b91a54e2b28
parentfb500a7cfee7f2f447d2bbf30cb59629feab6ac1
nfsd: Ensure we don't recognise lock stateids after freeing them

In order to deal with lookup races, nfsd4_free_lock_stateid() needs
to be able to signal to other stateful functions that the lock stateid
is no longer valid. Right now, nfsd_lock() will check whether or not an
existing stateid is still hashed, but only in the "new lock" path.

To ensure the stateid invalidation is also recognised by the "existing lock"
path, and also by a second call to nfsd4_free_lock_stateid() itself, we can
change the type to NFS4_CLOSED_STID under the stp->st_mutex.

Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
fs/nfsd/nfs4state.c