From: NeilBrown <neilb@suse.de>
To: Trond Myklebust <trondmy@hammerspace.com>,
"anna.schumaker\@netapp.com" <anna.schumaker@netapp.com>
Cc: "linux-nfs\@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH/RFC] NFS: handle NFSv4.1 server that doesn't support NFS4_OPEN_CLAIM_DELEG_CUR_FH
Date: Thu, 19 Dec 2019 13:56:14 +1100 [thread overview]
Message-ID: <87v9qdf2gh.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <3afd2d5c631d8e3429e025e204a7b1c95b3c1415.camel@hammerspace.com>
[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]
On Wed, Dec 18 2019, Trond Myklebust wrote:
> On Thu, 2019-12-19 at 09:47 +1100, NeilBrown wrote:
>> If an NFSv4.1 server doesn't support NFS4_OPEN_CLAIM_DELEG_CUR_FH
>> (e.g. Linux 3.0), and a newer NFS client tries to use it to claim
>> an open before returning a delegation, the server might return
>> NFS4ERR_BADXDR.
>> That is what Linux 3.0 does, though the RFC doesn't seem to be
>> explicit
>> on which flags must be supported, and what error can be returned for
>> unsupported flags.
>
> NFS4ERR_BADXDR is defined in RFC5661, section 15.1.1.1 as meaning
>
> "The arguments for this operation do not match those specified in the
> XDR definition."
>
> That's clearly not the case here, so I'd chalk this down to a fairly
> blatant server bug, at which point it makes no sense to fix it in the
> client.
Ok, but the RFC seems to suggest it is OK to not support this flag, so
suppose I fixed the server to return NFS4ERR_NOTSUPP instead.
The client still wouldn't handle this response gracefully.
Thanks,
NeilBrown
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index caacf5e7f5e1..14f958d16648 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2174,6 +2174,13 @@ static int nfs4_open_reclaim(struct nfs4_state_owner *sp, struct nfs4_state *sta
static int nfs4_handle_delegation_recall_error(struct nfs_server *server, struct nfs4_state *state, const
nfs4_stateid *stateid, struct file_lock *fl, int err)
{
switch (err) {
+ case -NFS4ERR_NOTSUPP: {
+ struct nfs4_exception exception;
+ if (nfs4_clear_cap_atomic_open_v1(server, -EINVAL,
+ &exception))
+ return -EAGAIN;
+ }
+ /* fallthrough */
default:
printk(KERN_ERR "NFS: %s: unhandled error "
"%d.\n", __func__, err);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-12-19 2:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 22:47 [PATCH/RFC] NFS: handle NFSv4.1 server that doesn't support NFS4_OPEN_CLAIM_DELEG_CUR_FH NeilBrown
2019-12-18 23:47 ` Trond Myklebust
2019-12-19 2:56 ` NeilBrown [this message]
2019-12-19 5:12 ` Trond Myklebust
2019-12-19 5:39 ` NeilBrown
2019-12-19 13:24 ` Trond Myklebust
2019-12-20 5:19 ` NeilBrown
2020-01-07 16:15 ` J. Bruce Fields
2020-01-07 16:53 ` J. Bruce Fields
2020-01-07 23:16 ` NeilBrown
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=87v9qdf2gh.fsf@notabene.neil.brown.name \
--to=neilb@suse.de \
--cc=anna.schumaker@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.com \
/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).