Linux NFS development
 help / color / mirror / Atom feed
From: Andrew W Elble <aweits@rit.edu>
To: Benjamin Coddington <bcodding@redhat.com>
Cc: Jeff Layton <jlayton@redhat.com>, <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] nfsd4: Prevent the reuse of a closed stateid
Date: Wed, 18 Oct 2017 20:48:36 -0400	[thread overview]
Message-ID: <m2o9p4vu6z.fsf@discipline.rit.edu> (raw)
In-Reply-To: <D68224FD-D466-4DF1-9CBF-EAF03976B9AF@redhat.com> (Benjamin Coddington's message of "Tue, 17 Oct 2017 16:40:05 -0400")


Benjamin Coddington <bcodding@redhat.com> writes:

> On 17 Oct 2017, at 14:19, Jeff Layton wrote:
>
>> Also we now have to take the st_mutex in nfsd4_find_existing_open, just to
>> check sc_type.  Neither of those are probably unreasonable, it's just
>> messier than I'd like.
>
> It is indeed messy.. no argument.  I'll spin up your suggestion to unhash
> the stateid before updating and take it for a ride and let you know the
> results.  Thanks for looking at this.

I threw this against a quick lockdep run and didn't see anything that
surprised me. I think we developed a harmless warning in
nfsd4_process_open2() a ways back?

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 94ef63a10146..87535f2688be 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -64,6 +64,9 @@
 static const stateid_t currentstateid = {
 	.si_generation = 1,
 };
+static const stateid_t invalidstateid = {
+        .si_generation = U32_MAX,
+};
 
 static u64 current_sessionid = 1;
 
@@ -5362,11 +5365,11 @@ static void nfsd4_close_open_stateid(struct nfs4_ol_stateid *s)
 	nfsd4_bump_seqid(cstate, status);
 	if (status)
 		goto out; 
-	nfs4_inc_and_copy_stateid(&close->cl_stateid, &stp->st_stid);
-	mutex_unlock(&stp->st_mutex);
+	memcpy(&close->cl_stateid, &invalidstateid, sizeof(stateid_t));
 
 	nfsd4_close_open_stateid(stp);
 
+	mutex_unlock(&stp->st_mutex);
 	/* put reference from nfs4_preprocess_seqid_op */
 	nfs4_put_stid(&stp->st_stid);
 out:
-- 
1.8.3.1

-- 
Andrew W. Elble
aweits@discipline.rit.edu
Infrastructure Engineer, Communications Technical Lead
Rochester Institute of Technology
PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912

  reply	other threads:[~2017-10-19  0:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-17 13:55 [PATCH] nfsd4: Prevent the reuse of a closed stateid Benjamin Coddington
2017-10-17 16:39 ` Jeff Layton
2017-10-17 17:46   ` Benjamin Coddington
2017-10-17 18:19     ` Jeff Layton
2017-10-17 20:40       ` Benjamin Coddington
2017-10-19  0:48         ` Andrew W Elble [this message]
2017-10-19 12:01           ` Benjamin Coddington
2017-10-17 19:11 ` Jeff Layton
2017-10-17 20:44   ` Benjamin Coddington
2017-11-10 22:03 ` J. Bruce Fields
2017-11-13 13:22   ` Benjamin Coddington

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=m2o9p4vu6z.fsf@discipline.rit.edu \
    --to=aweits@rit.edu \
    --cc=bcodding@redhat.com \
    --cc=jlayton@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox