From: "'J. Bruce Fields'" <bfields@fieldses.org>
To: Frank Filz <ffilzlnx@mindspring.com>
Cc: "'Mkrtchyan, Tigran'" <tigran.mkrtchyan@desy.de>,
"'Ulrich Gemkow'" <ulrich.gemkow@ikr.uni-stuttgart.de>,
linux-nfs@vger.kernel.org
Subject: Re: NFSv4 mount fails on Sun Solaris 10 after reboot of client
Date: Tue, 1 Sep 2015 13:43:35 -0400 [thread overview]
Message-ID: <20150901174335.GB32692@fieldses.org> (raw)
In-Reply-To: <20150828180612.GC10468@fieldses.org>
On Fri, Aug 28, 2015 at 02:06:12PM -0400, 'J. Bruce Fields' wrote:
> On Thu, Aug 27, 2015 at 01:36:38PM -0700, Frank Filz wrote:
> > If the creds don't match, the return should be NFS4ERR_CLID_INUSE per
> > section 16.34.5. IMPLEMENTATION first bullet after DRC discussion.
> >
> > At least the way I read RFC 7530...
>
> I assumed that was only the case when the long-form client-provided
> client identifier matched, but here we're looking at records matched by
> the shorthand server-generated clientid. Very weird that that we'd get
> to this case (and without hitting CLID_INUSE on the setclientid?).
> There's something we don't understand.
>
> Anyway, looking at the SETCLIENTID_CONFIRM description in 7530, I think
> you're right, they're recommending CLIDN_INUSE for this case. Doubt
> that would actually help in Ulrich's case, though.
May as well fix that anyway, I guess.--b.
commit 3d70e158ea9b
Author: J. Bruce Fields <bfields@redhat.com>
Date: Tue Sep 1 13:40:53 2015 -0400
nfsd: return CLID_INUSE for unexpected SETCLIENTID_CONFIRM case
Somebody with a Solaris client was hitting this case. We haven't
figured out why yet, and don't have a reproducer. Meanwhile Frank
noticed that RFC 7530 actually recommends CLID_INUSE for this case.
Unlikely to help the original reporter, but may as well fix it.
Reported-by: Frank Filz <ffilzlnx@mindspring.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 416f32e34a33..08746ec1d44a 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -3111,10 +3111,11 @@ nfsd4_setclientid_confirm(struct svc_rqst *rqstp,
/*
* We try hard to give out unique clientid's, so if we get an
* attempt to confirm the same clientid with a different cred,
- * there's a bug somewhere. Let's charitably assume it's our
- * bug.
+ * the client may be buggy; this should never happen.
+ *
+ * Nevertheless, RFC 7530 recommends INUSE for this case:
*/
- status = nfserr_serverfault;
+ status = nfserr_clid_inuse;
if (unconf && !same_creds(&unconf->cl_cred, &rqstp->rq_cred))
goto out;
if (conf && !same_creds(&conf->cl_cred, &rqstp->rq_cred))
prev parent reply other threads:[~2015-09-01 17:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-24 12:52 NFSv4 mount fails on Sun Solaris 10 after reboot of client Ulrich Gemkow
2015-08-24 20:14 ` J. Bruce Fields
2015-08-25 17:28 ` Ulrich Gemkow
2015-08-25 21:54 ` J. Bruce Fields
2015-08-26 19:54 ` Ulrich Gemkow
2015-08-26 20:09 ` J. Bruce Fields
2015-08-31 12:08 ` Ulrich Gemkow
2015-08-31 14:51 ` J. Bruce Fields
2015-08-31 15:52 ` Mkrtchyan, Tigran
2015-08-27 6:43 ` Mkrtchyan, Tigran
2015-08-27 18:29 ` J. Bruce Fields
2015-08-27 20:36 ` Frank Filz
2015-08-28 18:06 ` 'J. Bruce Fields'
2015-09-01 17:43 ` 'J. Bruce Fields' [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=20150901174335.GB32692@fieldses.org \
--to=bfields@fieldses.org \
--cc=ffilzlnx@mindspring.com \
--cc=linux-nfs@vger.kernel.org \
--cc=tigran.mkrtchyan@desy.de \
--cc=ulrich.gemkow@ikr.uni-stuttgart.de \
/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).