nfsd: hold ->cl_lock for hash_delegation_locked()
authorNeilBrown <neilb@suse.de>
Tue, 30 Jan 2024 01:08:22 +0000 (12:08 +1100)
committerChuck Lever <chuck.lever@oracle.com>
Fri, 1 Mar 2024 14:12:18 +0000 (09:12 -0500)
commit779457285a45cb95d625d407becd6417cb3d1c96
treee63f14ab7cf899bb0117d6cf1ba97d1c8509c8f5
parent6b4ca49dc310d107f36642c39b2c9e3fbf8ba3c9
nfsd: hold ->cl_lock for hash_delegation_locked()

The protocol for creating a new state in nfsd is to allocate the state
leaving it largely uninitialised, add that state to the ->cl_stateids
idr so as to reserve a state-id, then complete initialisation of the
state and only set ->sc_type to non-zero once the state is fully
initialised.

If a state is found in the idr with ->sc_type == 0, it is ignored.
The ->cl_lock lock is used to avoid races - it is held while checking
sc_type during lookup, and held when a non-zero value is stored in
->sc_type.

... except... hash_delegation_locked() finalises the initialisation of a
delegation state, but does NOT hold ->cl_lock.

So this patch takes ->cl_lock at the appropriate time w.r.t other locks,
and so ensures there are no races (which are extremely unlikely in any
case).
As ->fi_lock is often taken when ->cl_lock is held, we need to take
->cl_lock first of those two.
Currently ->cl_lock and state_lock are never both taken at the same time.
We need both for this patch so an arbitrary choice is needed concerning
which to take first.  As state_lock is more global, it might be more
contended, so take it first.

Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
fs/nfsd/nfs4state.c