[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-nfs
Subject:    Re: [PATCH] nfsd: On CLOSE, the state change needs to be atomic with the seqid bump
From:       Trond Myklebust <trondmy () primarydata ! com>
Date:       2017-10-30 18:35:31
Message-ID: 1509388529.95653.4.camel () primarydata ! com
[Download RAW message or body]

On Fri, 2017-10-27 at 16:25 -0400, Trond Myklebust wrote:
> The various functions that call check_stateid_generation() in order
> to compare a client-supplied stateid with the nfs4_stid state, almost
> without exception need to check for closed state.
> 
> A race now exists whereby the stateid can get bumped in nfsd4_close,
> but
> the actual change in value of st_stid.sc_type is deferred until after
> all locks are dropped.
> This commit ensures that the state change is logged while the state
> mutex is held, but also ensures that is happens before the seqid
> is bumped. It also adds locking and checks so that functions that
> check
> the seqid will also see the correct state.
> 

Turns out this patch is insufficient to prevent a race between CLOSE
and OPEN whereby the server ends up reusing a stateid that is already
closed. I've been testing a patch series that addresses that issue over
the weekend. Will send an update later today.

-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]