linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bfields@fieldses.org (J. Bruce Fields)
To: Jeff Layton <jlayton@redhat.com>
Cc: "J. Bruce Fields" <bfields@redhat.com>, linux-nfs@vger.kernel.org
Subject: Re: [0/2] make nfsd's setclientid behavior migration-friendly
Date: Thu, 22 Sep 2016 10:46:57 -0400	[thread overview]
Message-ID: <20160922144657.GC30401@fieldses.org> (raw)
In-Reply-To: <1474542423.1706.4.camel@redhat.com>

On Thu, Sep 22, 2016 at 07:07:03AM -0400, Jeff Layton wrote:
> On Wed, 2016-09-21 at 14:03 -0400, J. Bruce Fields wrote:
> > Clients mounting multiple servers with the "migration" option may find
> > some mounts are made from the incorrect server.
> > 
> > I think this is really a bug in RFC 7931, and that RFC and the client
> > need fixing, but this is easy to mitigate on the server.  I'll make an
> > attempt at a client patch too.
> > 
> > --b.
> > 
> > 
> 
> Both look reasonable to me:
> 
> Reviewed-by: Jeff Layton <jlayton@redhat.com>

Thanks.  The below (untested) is what I was thinking of for the client.

--b.

commit 0d210faff69c
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Wed Sep 21 15:49:21 2016 -0400

    nfs: fix false positives in nfs40_walk_client_list()
    
    It's possible that two different servers can return the same (clientid,
    verifier) pair purely by coincidence.  Both are 64-bit values, but
    depending on the server implementation, they can be highly predictable
    and collisions may be quite likely, especially when there are lots of
    servers.
    
    So, check for this case.  If the clientid and verifier both match, then
    we actually know they *can't* be the same server, since a new
    SETCLIENTID to an already-known server should have changed the verifier.
    
    This helps fix a bug that could cause the client to mount a filesystem
    from the wrong server.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index cd3b7cfdde16..a8cdb94d313c 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -461,6 +461,11 @@ static bool nfs4_match_client_owner_id(const struct nfs_client *clp1,
 	return strcmp(clp1->cl_owner_id, clp2->cl_owner_id) == 0;
 }
 
+static bool nfs4_same_verifier(nfs4_verifier *v1, nfs4_verifier *v2)
+{
+	return 0 == memcmp(v1->data, v2->data, sizeof(v1->data));
+}
+
 /**
  * nfs40_walk_client_list - Find server that recognizes a client ID
  *
@@ -518,7 +523,20 @@ int nfs40_walk_client_list(struct nfs_client *new,
 
 		if (!nfs4_match_client_owner_id(pos, new))
 			continue;
-
+		/*
+		 * We just sent a new SETCLIENTID, which should have
+		 * caused the server to return a new cl_confirm.  So if
+		 * cl_confirm is the same, then this is a different
+		 * server that just returned the same cl_confirm by
+		 * coincidence:
+		 */
+		if (nfs4_same_verifier(&pos->cl_confirm, &new->cl_confirm))
+			continue;
+		/*
+		 * But if the cl_confirm's are different, then the only
+		 * way that a SETCLIENTID_CONFIRM to pos can succeed is
+		 * if new and pos point to the same server:
+		 */
 		atomic_inc(&pos->cl_count);
 		spin_unlock(&nn->nfs_client_lock);
 

  reply	other threads:[~2016-09-22 14:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21 18:03 [0/2] make nfsd's setclientid behavior migration-friendly J. Bruce Fields
2016-09-21 18:03 ` [PATCH 1/2] nfsd: randomize SETCLIENTID reply to help distinguish servers J. Bruce Fields
2016-09-21 18:03 ` [PATCH 2/2] nfsd4: setclientid_confirm with unmatched verifier should fail J. Bruce Fields
2016-09-22 11:07 ` [0/2] make nfsd's setclientid behavior migration-friendly Jeff Layton
2016-09-22 14:46   ` J. Bruce Fields [this message]
2016-09-22 15:36     ` Jeff Layton
2016-09-22 20:23       ` J. Bruce Fields

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=20160922144657.GC30401@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bfields@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;
as well as URLs for NNTP newsgroup(s).