From: Jeff Layton <jlayton@kernel.org>
To: Mike Snitzer <snitzer@kernel.org>, Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, Anna Schumaker <anna@kernel.org>,
Trond Myklebust <trondmy@hammerspace.com>,
NeilBrown <neilb@suse.de>,
snitzer@hammerspace.com
Subject: Re: [PATCH v9 13/19] nfsd: add "localio" support
Date: Sun, 30 Jun 2024 15:52:51 -0400 [thread overview]
Message-ID: <359d5b252f6f5a7eb348c79beb00a9e6594b743c.camel@kernel.org> (raw)
In-Reply-To: <ZoG1pF_sgAUDoH-n@kernel.org>
On Sun, 2024-06-30 at 15:44 -0400, Mike Snitzer wrote:
> On Sun, Jun 30, 2024 at 10:49:51AM -0400, Chuck Lever wrote:
> > On Sat, Jun 29, 2024 at 06:18:42PM -0400, Chuck Lever wrote:
> > > > +
> > > > + /* nfs_fh -> svc_fh */
> > > > + if (nfs_fh->size > NFS4_FHSIZE) {
> > > > + status = -EINVAL;
> > > > + goto out;
> > > > + }
> > > > + fh_init(&fh, NFS4_FHSIZE);
> > > > + fh.fh_handle.fh_size = nfs_fh->size;
> > > > + memcpy(fh.fh_handle.fh_raw, nfs_fh->data, nfs_fh->size);
> > > > +
> > > > + if (fmode & FMODE_READ)
> > > > + mayflags |= NFSD_MAY_READ;
> > > > + if (fmode & FMODE_WRITE)
> > > > + mayflags |= NFSD_MAY_WRITE;
> > > > +
> > > > + beres = nfsd_file_acquire(rqstp, &fh, mayflags, &nf);
> > > > + if (beres) {
> > > > + status = nfs_stat_to_errno(be32_to_cpu(beres));
> > > > + goto out_fh_put;
> > > > + }
> > >
> > > So I'm wondering whether just calling fh_verify() and then
> > > nfsd_open_verified() would be simpler and/or good enough here. Is
> > > there a strong reason to use the file cache for locally opened
> > > files? Jeff, any thoughts?
> >
> > > Will there be writeback ramifications for
> > > doing this? Maybe we need a comment here explaining how these files
> > > are garbage collected (just an fput by the local I/O client, I would
> > > guess).
> >
> > OK, going back to this: Since right here we immediately call
> >
> > nfsd_file_put(nf);
> >
> > There are no writeback ramifications nor any need to comment about
> > garbage collection. But this still seems like a lot of (possibly
> > unnecessary) overhead for simply obtaining a struct file.
>
> Easy enough change, probably best to avoid the filecache but would like
> to verify with Jeff before switching:
>
> diff --git a/fs/nfsd/localio.c b/fs/nfsd/localio.c
> index 1d6508aa931e..85ebf63789fb 100644
> --- a/fs/nfsd/localio.c
> +++ b/fs/nfsd/localio.c
> @@ -197,7 +197,6 @@ int nfsd_open_local_fh(struct net *cl_nfssvc_net,
> const struct cred *save_cred;
> struct svc_rqst *rqstp;
> struct svc_fh fh;
> - struct nfsd_file *nf;
> __be32 beres;
>
> if (nfs_fh->size > NFS4_FHSIZE)
> @@ -235,13 +234,12 @@ int nfsd_open_local_fh(struct net *cl_nfssvc_net,
> if (fmode & FMODE_WRITE)
> mayflags |= NFSD_MAY_WRITE;
>
> - beres = nfsd_file_acquire(rqstp, &fh, mayflags, &nf);
> + beres = fh_verify(rqstp, &fh, S_IFREG, mayflags);
> if (beres) {
> status = nfs_stat_to_errno(be32_to_cpu(beres));
> goto out_fh_put;
> }
> - *pfilp = get_file(nf->nf_file);
> - nfsd_file_put(nf);
> + status = nfsd_open_verified(rqstp, &fh, mayflags, pfilp);
> out_fh_put:
> fh_put(&fh);
> nfsd_local_fakerqst_destroy(rqstp);
>
My suggestion would be to _not_ do this. I think you do want to use the
filecache (mostly for performance reasons).
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2024-06-30 19:52 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 21:10 [PATCH v9 00/19] nfs/nfsd: add support for localio Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 01/19] nfs: pass nfs_client to nfs_initiate_pgio Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 02/19] nfs: pass descriptor thru nfs_initiate_pgio path Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 03/19] nfs: pass struct file to nfs_init_pgio and nfs_init_commit Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 04/19] sunrpc: add rpcauth_map_to_svc_cred_local Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 05/19] nfs_common: add NFS LOCALIO auxiliary protocol enablement Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 06/19] nfs: add "localio" support Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 07/19] nfs/localio: fix nfs_localio_vfs_getattr() to properly support v4 Mike Snitzer
2024-06-29 15:50 ` Chuck Lever
2024-06-30 22:01 ` NeilBrown
2024-06-30 22:23 ` Chuck Lever
2024-06-28 21:10 ` [PATCH v9 08/19] nfs: enable localio for non-pNFS I/O Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 09/19] pnfs/flexfiles: Enable localio for flexfiles I/O Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 10/19] nfs: factor out {encode,decode}_opaque_fixed to nfs_xdr.h Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 11/19] SUNRPC: remove call_allocate() BUG_ON if p_arglen=0 to allow RPC with void arg Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 12/19] nfs: implement client support for NFS_LOCALIO_PROGRAM Mike Snitzer
2024-06-28 21:10 ` [PATCH v9 13/19] nfsd: add "localio" support Mike Snitzer
2024-06-29 22:18 ` Chuck Lever
2024-06-30 14:49 ` Chuck Lever
2024-06-30 19:44 ` Mike Snitzer
2024-06-30 19:52 ` Jeff Layton [this message]
2024-06-30 19:55 ` Chuck Lever
2024-06-30 19:59 ` Jeff Layton
2024-06-30 20:15 ` Chuck Lever
2024-06-30 21:07 ` Jeff Layton
2024-06-30 21:56 ` NeilBrown
2024-06-30 21:54 ` NeilBrown
2024-07-01 1:29 ` NeilBrown
2024-06-30 19:51 ` Jeff Layton
2024-06-30 22:22 ` NeilBrown
2024-06-30 22:34 ` Chuck Lever
2024-06-28 21:11 ` [PATCH v9 14/19] nfsd/localio: manage netns reference in nfsd_open_local_fh Mike Snitzer
2024-06-28 21:11 ` [PATCH v9 15/19] nfsd: use percpu_ref to interlock nfsd_destroy_serv and nfsd_open_local_fh Mike Snitzer
2024-06-28 21:11 ` [PATCH v9 16/19] nfsd: add Kconfig options to allow localio to be enabled Mike Snitzer
2024-06-28 21:11 ` [PATCH v9 17/19] nfsd: implement server support for NFS_LOCALIO_PROGRAM Mike Snitzer
2024-06-28 21:11 ` [PATCH v9 18/19] SUNRPC: replace program list with program array Mike Snitzer
2024-06-29 16:00 ` Chuck Lever
2024-06-30 21:57 ` NeilBrown
2024-06-28 21:11 ` [PATCH v9 19/19] nfs: add Documentation/filesystems/nfs/localio.rst Mike Snitzer
2024-06-29 15:36 ` [PATCH v9 00/19] nfs/nfsd: add support for localio Chuck Lever III
2024-06-29 16:03 ` Mike Snitzer
2024-06-29 17:01 ` Chuck Lever
2024-06-29 19:10 ` Mike Snitzer
2024-06-29 20:31 ` Chuck Lever III
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=359d5b252f6f5a7eb348c79beb00a9e6594b743c.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=snitzer@hammerspace.com \
--cc=snitzer@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