linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Trond Myklebust <trond.myklebust@hammerspace.com>,
	Anna Schumaker <anna.schumaker@netapp.com>
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH/RFC] NFS: handle NFSv4.1 server that doesn't support NFS4_OPEN_CLAIM_DELEG_CUR_FH
Date: Thu, 19 Dec 2019 09:47:23 +1100	[thread overview]
Message-ID: <87y2v9fdz8.fsf@notabene.neil.brown.name> (raw)

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]


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.

When NFS_CAP_ATOMIC_OPEN_V1 support was added in Commit 49f9a0fafd84
("NFSv4.1: Enable open-by-filehandle"), fall-back for non-supporting
servers was added for various open types, but not for delegation recall.

The code pattern for delegation recall is a little different to the
other open types, so I cannot simply copy the same approach.

I think the below patch should do the right thing, but I haven't tested
yet.

Does this look reasonable?  Is there a cleaner way to do it?  Should
we check other errors?

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_BADXDR: {
+			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 --]

             reply	other threads:[~2019-12-18 22:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 22:47 NeilBrown [this message]
2019-12-18 23:47 ` [PATCH/RFC] NFS: handle NFSv4.1 server that doesn't support NFS4_OPEN_CLAIM_DELEG_CUR_FH Trond Myklebust
2019-12-19  2:56   ` NeilBrown
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=87y2v9fdz8.fsf@notabene.neil.brown.name \
    --to=neilb@suse.de \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@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).