From: Scott Mayhew <smayhew@redhat.com>
To: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH] NFSv4: deal with v4.0 servers that request confirmation on reclaim-type opens
Date: Fri, 30 Nov 2018 12:41:51 -0500 [thread overview]
Message-ID: <20181130174151.19448-2-smayhew@redhat.com> (raw)
In-Reply-To: <20181130174151.19448-1-smayhew@redhat.com>
There are some NFS v4.0 servers that request confirmation on
reclaim-type opens even though it is disallowed by RFC 7530.
The Linux NFS client used to cope with those okay due to
1) nfs4_opendata_alloc() setting the filehandle in the args for the
OPEN_CONFIRM to point to the filehandle in the OPEN results, and
2) nfs4_open_prepare() copying the filehandle from the OPEN args to the
OPEN results when doing an open by filehandle
The latter part was removed by commit 4e2fcac77390 ("nfsv4: Use correct
inode in _nfs4_opendata_to_nfs4_state()")... and since there's no GETFH
in the OPEN compound when doing a reclaim-type open, if one of these
servers does request confirmation we wind up sending a zero filehandle
in the PUTFH of the OPEN_CONFIRM compound and the OPEN_CONFIRM fails
with NFS4ERR_BADHANDLE, causing the reclaim to fail.
Add the copying of the filehandle back to nfs4_open_prepare() and
log a warning in the event that the client does get a reply to
OPEN(CLAIM_PREVIOUS) that has NFS4_OPEN_RESULT_CONFIRM set.
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
---
fs/nfs/nfs4proc.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 867457d6dfbe..5e521a506da3 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2323,6 +2323,7 @@ static void nfs4_open_prepare(struct rpc_task *task, void *calldata)
/* Fall through */
case NFS4_OPEN_CLAIM_FH:
task->tk_msg.rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_OPEN_NOATTR];
+ nfs_copy_fh(&data->o_res.fh, data->o_arg.fh);
}
data->timestamp = jiffies;
if (nfs4_setup_sequence(data->o_arg.server->nfs_client,
@@ -2470,8 +2471,14 @@ static int _nfs4_recover_proc_open(struct nfs4_opendata *data)
nfs_fattr_map_and_free_names(NFS_SERVER(dir), &data->f_attr);
- if (o_res->rflags & NFS4_OPEN_RESULT_CONFIRM)
+ if (o_res->rflags & NFS4_OPEN_RESULT_CONFIRM) {
+ if (data->o_arg.claim == NFS4_OPEN_CLAIM_PREVIOUS)
+ pr_err_ratelimited("NFS: Broken NFSv4 server %s is "
+ "requesting open confirmation for "
+ "OPEN(CLAIM_PREVIOUS)\n",
+ NFS_SERVER(dir)->nfs_client->cl_hostname);
status = _nfs4_proc_open_confirm(data);
+ }
return status;
}
--
2.17.1
next prev parent reply other threads:[~2018-11-30 17:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 17:41 [PATCH 0/1] NFSv4: deal with v4.0 servers that request confirmation on reclaim-type opens Scott Mayhew
2018-11-30 17:41 ` Scott Mayhew [this message]
2018-11-30 18:48 ` [PATCH] " Trond Myklebust
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=20181130174151.19448-2-smayhew@redhat.com \
--to=smayhew@redhat.com \
--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