linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Neil Brown <neilb@suse.de>, Olga Kornievskaia <kolga@netapp.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Jonathan Corbet <corbet@lwn.net>, Tom Haynes <loghyr@gmail.com>,
	linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
	 linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3 03/13] nfsd: drop the ncf_cb_bmap field
Date: Wed, 04 Sep 2024 12:58:38 -0400	[thread overview]
Message-ID: <82b17019fb334973a74adf88e3eb255df4091f12.camel@kernel.org> (raw)
In-Reply-To: <Zth6oPq1GV2iiypL@tissot.1015granger.net>

On Wed, 2024-09-04 at 11:20 -0400, Chuck Lever wrote:
> On Thu, Aug 29, 2024 at 09:26:41AM -0400, Jeff Layton wrote:
> > This is always the same value, and in a later patch we're going to need
> > to set bits in WORD2. We can simplify this code and save a little space
> > in the delegation too. Just hardcode the bitmap in the callback encode
> > function.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> 
> OK, lurching forward on this ;-)
> 
>  - The first patch in v3 was applied to v6.11-rc.
>  - The second patch is now in nfsd-next.
>  - I've squashed the sixth and eighth patches into nfsd-next.
> 
> I'm replying to this patch because this one seems like a step
> backwards to me: the bitmap values are implementation-dependent,
> and this code will eventually be automatically generated based only
> on the protocol, not the local implementation. IMO, architecturally,
> bitmap values should be set at the proc layer, not in the encoders.
> 
> I've gone back and forth on whether to just go with it for now, but
> I thought I'd mention it here to see if this change is truly
> necessary for what follows. If it can't be replaced, I will suck it
> up and fix it up later when this encoder is converted to an xdrgen-
> manufactured one.

It's not truly necessary, but I don't see why it's important that we
keep a record of the full-blown bitmap here. The ncf_cb_bmap field is a
field in the delegation record, and it has to be carried around in
perpetuity. This value is always set by the server and there are only a
few legit bit combinations that can be set in it.

We certainly can keep this bitmap around, but as I said in the
description, the delstid draft grows this bitmap to 3 words, and if we
want to be a purists about storing a bitmap, then that will also
require us to keep the bitmap size (in another 32-bit word), since we
don't always want to set anything in the third word. That's already 24
extra bits per delegation, and we'll be adding new fields for the
timestamps in a later patch.

I don't see the benefit here.

> I've tried to apply a few of the following patches in this series,
> but by 9/13, things stop compiling. So I will let you rebase your
> work on the current nfsd-next and redrive it, and we can go from
> there.
> 

Great. I'll rebase and re-test.

PS: I'm working on a couple of pynfs tests for CB_GETATTR as well. I'll
post them once I have them working. I've also found nfsd bugs in how we
currently proxy the attrs. I'll have patches for that in the next
posting (once my question on the IETF list is answered).

> 
> > ---
> >  fs/nfsd/nfs4callback.c | 5 ++++-
> >  fs/nfsd/nfs4state.c    | 1 -
> >  fs/nfsd/state.h        | 1 -
> >  3 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c
> > index b5b3ab9d719a..0c49e31d4350 100644
> > --- a/fs/nfsd/nfs4callback.c
> > +++ b/fs/nfsd/nfs4callback.c
> > @@ -364,10 +364,13 @@ encode_cb_getattr4args(struct xdr_stream *xdr, struct nfs4_cb_compound_hdr *hdr,
> >  	struct nfs4_delegation *dp =
> >  		container_of(fattr, struct nfs4_delegation, dl_cb_fattr);
> >  	struct knfsd_fh *fh = &dp->dl_stid.sc_file->fi_fhandle;
> > +	u32 bmap[1];
> > +
> > +	bmap[0] = FATTR4_WORD0_CHANGE | FATTR4_WORD0_SIZE;
> >  
> >  	encode_nfs_cb_opnum4(xdr, OP_CB_GETATTR);
> >  	encode_nfs_fh4(xdr, fh);
> > -	encode_bitmap4(xdr, fattr->ncf_cb_bmap, ARRAY_SIZE(fattr->ncf_cb_bmap));
> > +	encode_bitmap4(xdr, bmap, ARRAY_SIZE(bmap));
> >  	hdr->nops++;
> >  }
> >  
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index 8835930ecee6..6844ae9ea350 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -1183,7 +1183,6 @@ alloc_init_deleg(struct nfs4_client *clp, struct nfs4_file *fp,
> >  	nfsd4_init_cb(&dp->dl_cb_fattr.ncf_getattr, dp->dl_stid.sc_client,
> >  			&nfsd4_cb_getattr_ops, NFSPROC4_CLNT_CB_GETATTR);
> >  	dp->dl_cb_fattr.ncf_file_modified = false;
> > -	dp->dl_cb_fattr.ncf_cb_bmap[0] = FATTR4_WORD0_CHANGE | FATTR4_WORD0_SIZE;
> >  	get_nfs4_file(fp);
> >  	dp->dl_stid.sc_file = fp;
> >  	return dp;
> > diff --git a/fs/nfsd/state.h b/fs/nfsd/state.h
> > index 79c743c01a47..ac3a29224806 100644
> > --- a/fs/nfsd/state.h
> > +++ b/fs/nfsd/state.h
> > @@ -138,7 +138,6 @@ struct nfs4_cpntf_state {
> >  struct nfs4_cb_fattr {
> >  	struct nfsd4_callback ncf_getattr;
> >  	u32 ncf_cb_status;
> > -	u32 ncf_cb_bmap[1];
> >  
> >  	/* from CB_GETATTR reply */
> >  	u64 ncf_cb_change;
> > 
> > -- 
> > 2.46.0
> > 
> 
> 
> 

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2024-09-04 16:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-29 13:26 [PATCH v3 00/13] nfsd: implement the "delstid" draft Jeff Layton
2024-08-29 13:26 ` [PATCH v3 01/13] nfsd: fix nfsd4_deleg_getattr_conflict in presence of third party lease Jeff Layton
2024-08-29 15:17   ` Chuck Lever
2024-08-30  6:01     ` NeilBrown
2024-08-30 13:54       ` Chuck Lever III
2024-08-29 13:26 ` [PATCH v3 02/13] nfsd: untangle code in nfsd4_deleg_getattr_conflict() Jeff Layton
2024-08-29 13:26 ` [PATCH v3 03/13] nfsd: drop the ncf_cb_bmap field Jeff Layton
2024-09-04 15:20   ` Chuck Lever
2024-09-04 16:58     ` Jeff Layton [this message]
2024-09-04 17:28       ` Chuck Lever III
2024-09-04 17:39         ` Jeff Layton
2024-09-04 17:45           ` Chuck Lever III
2024-09-05  1:44             ` NeilBrown
2024-08-29 13:26 ` [PATCH v3 04/13] nfsd: drop the nfsd4_fattr_args "size" field Jeff Layton
2024-08-29 13:26 ` [PATCH v3 05/13] nfsd: have nfsd4_deleg_getattr_conflict pass back write deleg pointer Jeff Layton
2024-08-29 13:26 ` [PATCH v3 06/13] nfsd: add pragma public to delegated timestamp types Jeff Layton
2024-08-29 15:19   ` Chuck Lever
2024-08-29 13:26 ` [PATCH v3 07/13] nfsd: fix reported change attr on a write delegation Jeff Layton
2024-08-29 13:26 ` [PATCH v3 08/13] nfs_common: make nfs4.h include generated nfs4_1.h Jeff Layton
2024-08-29 15:13   ` Chuck Lever
2024-08-29 15:28     ` Chuck Lever
2024-08-29 18:26     ` Jeff Layton
2024-08-29 19:02       ` Chuck Lever III
2024-08-30 14:48       ` Chuck Lever III
2024-08-30 15:44         ` Jeff Layton
2024-08-30 17:48           ` Jeff Layton
2024-08-29 13:26 ` [PATCH v3 09/13] nfsd: add support for FATTR4_OPEN_ARGUMENTS Jeff Layton
2024-08-29 13:26 ` [PATCH v3 10/13] nfsd: implement OPEN_ARGS_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION Jeff Layton
2024-08-29 13:26 ` [PATCH v3 11/13] fs: handle delegated timestamps in setattr_copy_mgtime Jeff Layton
2024-09-02 13:22   ` Jan Kara
2024-08-29 13:26 ` [PATCH v3 12/13] nfsd: add support for delegated timestamps Jeff Layton
2024-08-29 13:26 ` [PATCH v3 13/13] nfsd: handle delegated timestamps in SETATTR Jeff Layton

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=82b17019fb334973a74adf88e3eb255df4091f12.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=anna@kernel.org \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=corbet@lwn.net \
    --cc=jack@suse.cz \
    --cc=kolga@netapp.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=loghyr@gmail.com \
    --cc=neilb@suse.de \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    --cc=trondmy@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).