From: cel@kernel.org
To: Neil Brown <neilb@suse.de>, Mike Snitzer <snitzer@kernel.org>
Cc: <linux-nfs@vger.kernel.org>, Chuck Lever <chuck.lever@oracle.com>
Subject: [RFC PATCH 3/6] NFSD: Avoid using rqstp->rq_vers in nfsd_set_fh_dentry()
Date: Tue, 27 Aug 2024 20:44:42 -0400 [thread overview]
Message-ID: <20240828004445.22634-4-cel@kernel.org> (raw)
In-Reply-To: <20240828004445.22634-1-cel@kernel.org>
From: Chuck Lever <chuck.lever@oracle.com>
Currently, fh_verify() makes some daring assumptions about which
version of file handle the caller wants, based on the things it can
find in the passed-in rqstp. The about-to-be-introduced LOCALIO use
case sometimes has no svc_rqst context, so this logic won't work in
that case.
Instead, examine the passed-in file handle. It's .max_size field
should carry information to allow nfsd_set_fh_dentry() to initialize
the file handle appropriately.
lockd appears to be the only kernel consumer that does not set the
file handle .max_size when during initialization.
write_filehandle() is the other question mark, as it looks possible
to specify a maxsize between NFS_FHSIZE and NFS3_FHSIZE here.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
fs/nfsd/lockd.c | 6 ++++--
fs/nfsd/nfsfh.c | 11 +++++++----
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/fs/nfsd/lockd.c b/fs/nfsd/lockd.c
index 46a7f9b813e5..e636d2a1e664 100644
--- a/fs/nfsd/lockd.c
+++ b/fs/nfsd/lockd.c
@@ -32,8 +32,10 @@ nlm_fopen(struct svc_rqst *rqstp, struct nfs_fh *f, struct file **filp,
int access;
struct svc_fh fh;
- /* must initialize before using! but maxsize doesn't matter */
- fh_init(&fh,0);
+ if (rqstp->rq_vers == 4)
+ fh_init(&fh, NFS3_FHSIZE);
+ else
+ fh_init(&fh, NFS_FHSIZE);
fh.fh_handle.fh_size = f->size;
memcpy(&fh.fh_handle.fh_raw, f->data, f->size);
fh.fh_export = NULL;
diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
index 4b964a71a504..77acc26e8b02 100644
--- a/fs/nfsd/nfsfh.c
+++ b/fs/nfsd/nfsfh.c
@@ -267,25 +267,28 @@ static __be32 nfsd_set_fh_dentry(struct svc_rqst *rqstp, struct svc_fh *fhp)
fhp->fh_dentry = dentry;
fhp->fh_export = exp;
- switch (rqstp->rq_vers) {
- case 4:
+ switch (fhp->fh_maxsize) {
+ case NFS4_FHSIZE:
if (dentry->d_sb->s_export_op->flags & EXPORT_OP_NOATOMIC_ATTR)
fhp->fh_no_atomic_attr = true;
fhp->fh_64bit_cookies = true;
break;
- case 3:
+ case NFS3_FHSIZE:
if (dentry->d_sb->s_export_op->flags & EXPORT_OP_NOWCC)
fhp->fh_no_wcc = true;
fhp->fh_64bit_cookies = true;
if (exp->ex_flags & NFSEXP_V4ROOT)
goto out;
break;
- case 2:
+ case NFS_FHSIZE:
fhp->fh_no_wcc = true;
if (EX_WGATHER(exp))
fhp->fh_use_wgather = true;
if (exp->ex_flags & NFSEXP_V4ROOT)
goto out;
+ break;
+ case 0:
+ WARN_ONCE(1, "Uninitialized file handle");
}
return 0;
--
2.45.2
next prev parent reply other threads:[~2024-08-28 0:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 0:44 [RFC PATCH 0/6] Split up refactoring of fh_verify() cel
2024-08-28 0:44 ` [RFC PATCH 1/6] NFSD: Handle @rqstp == NULL in check_nfsd_access() cel
2024-08-28 1:12 ` NeilBrown
2024-08-28 3:00 ` Mike Snitzer
2024-08-28 6:30 ` NeilBrown
2024-08-28 13:26 ` Chuck Lever III
2024-08-28 13:45 ` Mike Snitzer
2024-08-28 21:05 ` NeilBrown
2024-08-29 0:27 ` Mike Snitzer
2024-08-28 0:44 ` [RFC PATCH 2/6] NFSD: Refactor nfsd_setuser_and_check_port() cel
2024-08-28 0:44 ` cel [this message]
2024-08-28 5:02 ` [RFC PATCH 3/6] NFSD: Avoid using rqstp->rq_vers in nfsd_set_fh_dentry() NeilBrown
2024-08-28 13:45 ` Chuck Lever
2024-08-28 14:19 ` Mike Snitzer
2024-08-28 0:44 ` [RFC PATCH 4/6] NFSD: Short-circuit fh_verify tracepoints for LOCALIO cel
2024-08-28 0:44 ` [RFC PATCH 5/6] nfsd: factor out __fh_verify to allow NULL rqstp to be passed cel
2024-08-28 0:44 ` [RFC PATCH 6/6] nfsd: add nfsd_file_acquire_local() cel
2024-08-28 1:08 ` [RFC PATCH 0/6] Split up refactoring of fh_verify() Mike Snitzer
2024-08-28 2:32 ` Mike Snitzer
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=20240828004445.22634-4-cel@kernel.org \
--to=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=snitzer@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