All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2] nfsd: Fix race between FREE_STATEID and LOCK
Date: Sun, 7 Aug 2016 23:48:46 -0700	[thread overview]
Message-ID: <20160808064846.GA2079@infradead.org> (raw)
In-Reply-To: <20160807185024.11705.10864.stgit@klimt.1015granger.net>

On Sun, Aug 07, 2016 at 02:53:07PM -0400, Chuck Lever wrote:
> When running LTP's nfslock01 test, the Linux client can send a LOCK
> and a FREE_STATEID request at the same time. The LOCK uses the same
> lockowner as the stateid sent in the FREE_STATEID request.
> 
> The outcome is:
> 
> Frame 115025 C FREE_STATEID stateid 2/A
> Frame 115026 C LOCK offset 672128 len 64
> Frame 115029 R FREE_STATEID NFS4_OK
> Frame 115030 R LOCK stateid 3/A
> Frame 115034 C WRITE stateid 0/A offset 672128 len 64
> Frame 115038 R WRITE NFS4ERR_BAD_STATEID
> 
> In other words, the server returns stateid A in a successful LOCK
> reply, but it has already released it. Subsequent uses of the
> stateid fail.
> 
> To address this, protect the generation check in nfsd4_free_stateid
> with the st_mutex. This should guarantee that only one of two
> outcomes occurs: either LOCK returns a fresh valid stateid, or
> FREE_STATEID returns NFS4ERR_LOCKS_HELD.
> 
> Reported-by: Alexey Kodanev <alexey.kodanev@oracle.com>
> Fix-suggested-by: Jeff Layton <jlayton@redhat.com>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
>  fs/nfsd/nfs4state.c |   19 ++++++++++++-------
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index b921123..07dc1aa 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -4911,19 +4911,20 @@ nfsd4_free_stateid(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
>  		ret = nfserr_locks_held;
>  		break;
>  	case NFS4_LOCK_STID:
> +		atomic_inc(&s->sc_count);
> +		spin_unlock(&cl->cl_lock);
> +		stp = openlockstateid(s);
> +		mutex_lock(&stp->st_mutex);
>  		ret = check_stateid_generation(stateid, &s->sc_stateid, 1);
>  		if (ret)
> -			break;
> -		stp = openlockstateid(s);
> +			goto out_mutex_unlock;
>  		ret = nfserr_locks_held;
>  		if (check_for_locks(stp->st_stid.sc_file,
>  				    lockowner(stp->st_stateowner)))
> -			break;
> -		WARN_ON(!unhash_lock_stateid(stp));
> -		spin_unlock(&cl->cl_lock);
> -		nfs4_put_stid(s);
> +			goto out_mutex_unlock;
> +		release_lock_stateid(stp);
>  		ret = nfs_ok;
> -		goto out;
> +		goto out_mutex_unlock;

It would be nice to split the non-trivial cases (at least
NFS4_LOCK_STID and NFS4_REVOKED_DELEG_STID) into separate helpers
here as a follow on patch..

      parent reply	other threads:[~2016-08-08  6:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-07 18:53 [PATCH v2] nfsd: Fix race between FREE_STATEID and LOCK Chuck Lever
2016-08-07 22:22 ` Jeff Layton
2016-08-08 13:19   ` Jeff Layton
2016-08-08 16:14     ` Chuck Lever
2016-08-08 18:58       ` Jeff Layton
2016-08-08 19:53       ` J. Bruce Fields
2016-08-08 20:17         ` Jeff Layton
2016-08-08  6:48 ` Christoph Hellwig [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160808064846.GA2079@infradead.org \
    --to=hch@infradead.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.