Linux Documentation
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <cel@kernel.org>,
	Chuck Lever <chuck.lever@oracle.com>,
	 NeilBrown <neil@brown.name>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>,  Tom Talpey <tom@talpey.com>,
	Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	 Jonathan Corbet	 <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Alexander Aring <alex.aring@gmail.com>,
	 Amir Goldstein <amir73il@gmail.com>, Jan Kara <jack@suse.cz>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 Christian Brauner	 <brauner@kernel.org>,
	Calum Mackay <calum.mackay@oracle.com>,
	 linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	 linux-nfs@vger.kernel.org
Subject: Re: [PATCH v5 05/21] nfsd: update the fsnotify mark when setting or removing a dir delegation
Date: Wed, 10 Jun 2026 09:49:17 -0400	[thread overview]
Message-ID: <dd5836b365946641824dbde5b6edc5395271617d.camel@kernel.org> (raw)
In-Reply-To: <e0e995e9-8272-44f6-b2e0-9e61ed0eef3b@app.fastmail.com>

On Mon, 2026-06-08 at 12:38 -0400, Chuck Lever wrote:
> 
> On Fri, May 22, 2026, at 3:42 PM, Jeff Layton wrote:
> > Add a new helper function that will update the mask on the nfsd_file's
> > fsnotify_mark to be a union of all current directory delegations on an
> > inode. Call that when directory delegations are added or removed.
> 
> This commit message repeats what the diff below says. Can it instead
> explain why this change is necessary?
> 

The idea is that as new delegations are added or removed, the mask of
events that nfsd requires from the VFS layer can change, since clients
can request notifications of different events. I'll add that to the
changelog. 

> 
> > Reviewed-by: Jan Kara <jack@suse.cz>
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> >  fs/nfsd/nfs4state.c | 34 ++++++++++++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> > 
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index 2a34ba457b74..efbc99f0a965 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -1246,6 +1246,38 @@ static void 
> > nfsd4_finalize_deleg_timestamps(struct nfs4_delegation *dp, struct f
> >  	nfsd_update_cmtime_attr(f, ATTR_ATIME);
> >  }
> > 
> > +static void nfsd_fsnotify_recalc_mask(struct nfsd_file *nf)
> 
> Since nfsd_fsnotify_recalc_mask() takes a single struct nfsd_file
> as an argument, should this function reside in fs/nfsd/filecache.c
> instead? The question might reflect my misunderstanding of the
> new function's purpose.
> 

The only caller is in this file, so by keeping it here we can make it
static. I can change that if you'd prefer it be in filecache.c.

> 
> > +{
> > +	struct inode *inode = file_inode(nf->nf_file);
> > +	u32 lease_mask, set = 0, clear = 0;
> > +	struct fsnotify_mark *mark;
> > +
> > +	/* This is only needed when adding or removing dir delegs */
> > +	if (!S_ISDIR(inode->i_mode) || !nf->nf_mark)
> > +		return;
> > +
> > +	/* Set up notifications for any ignored delegation events */
> > +	lease_mask = inode_lease_ignore_mask(inode);
> > +	mark = &nf->nf_mark->nfm_mark;
> > +
> > +	if (lease_mask & FL_IGN_DIR_CREATE)
> > +		set |= FS_CREATE | FS_MOVED_TO;
> > +	else
> > +		clear |= FS_CREATE | FS_MOVED_TO;
> > +
> > +	if (lease_mask & FL_IGN_DIR_DELETE)
> > +		set |= FS_DELETE | FS_MOVED_FROM;
> > +	else
> > +		clear |= FS_DELETE | FS_MOVED_FROM;
> > +
> > +	if (lease_mask & FL_IGN_DIR_RENAME)
> > +		set |= FS_RENAME;
> > +	else
> > +		clear |= FS_RENAME;
> > +
> > +	fsnotify_modify_mark_mask(mark, set, clear);
> > +}
> > +
> >  static void nfs4_unlock_deleg_lease(struct nfs4_delegation *dp)
> >  {
> >  	struct nfs4_file *fp = dp->dl_stid.sc_file;
> > @@ -1255,6 +1287,7 @@ static void nfs4_unlock_deleg_lease(struct 
> > nfs4_delegation *dp)
> > 
> >  	nfsd4_finalize_deleg_timestamps(dp, nf->nf_file);
> >  	kernel_setlease(nf->nf_file, F_UNLCK, NULL, (void **)&dp);
> > +	nfsd_fsnotify_recalc_mask(nf);
> >  	put_deleg_file(fp);
> >  }
> > 
> 
> I added the following edit to this patch>
> 
> @@ -9597,8 +9629,7 @@ nfsd4_deleg_getattr_conflict(struct svc_rqst *rqstp, struct dentry *dentry,
>   * @nf: nfsd_file opened on the directory
>   *
>   * Given a GET_DIR_DELEGATION request @gdd, attempt to acquire a delegation
> - * on the directory to which @nf refers. Note that this does not set up any
> - * sort of async notifications for the delegation.
> + * on the directory to which @nf refers.
>   */
>  struct nfs4_delegation *
>  nfsd_get_dir_deleg
> 
> The patch makes the above kerneldoc note ("does not set up any sort of async
> notifications") logically obsolete.
> 

Thanks. I folded that change into this patch.

> 
> > @@ -9682,6 +9715,7 @@ nfsd_get_dir_deleg(struct nfsd4_compound_state *cstate,
> > 
> >  	if (!status) {
> >  		put_nfs4_file(fp);
> > +		nfsd_fsnotify_recalc_mask(nf);
> >  		return dp;
> >  	}
> > 
> > 
> > -- 
> > 2.54.0

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2026-06-10 13:49 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-22 19:42 [PATCH v5 00/21] nfsd: add support for CB_NOTIFY callbacks in directory delegations Jeff Layton
2026-05-22 19:42 ` [PATCH v5 01/21] nfsd: check fl_lmops in nfsd_breaker_owns_lease() Jeff Layton
2026-05-22 19:42 ` [PATCH v5 02/21] nfsd: add protocol support for CB_NOTIFY Jeff Layton
2026-05-22 19:42 ` [PATCH v5 03/21] nfs_common: add new NOTIFY4_* flags proposed in RFC8881bis Jeff Layton
2026-05-22 19:42 ` [PATCH v5 04/21] nfsd: allow nfsd to get a dir lease with an ignore mask Jeff Layton
2026-06-08 16:29   ` Chuck Lever
2026-05-22 19:42 ` [PATCH v5 05/21] nfsd: update the fsnotify mark when setting or removing a dir delegation Jeff Layton
2026-06-08 16:38   ` Chuck Lever
2026-06-10 13:49     ` Jeff Layton [this message]
2026-06-10 13:55       ` Chuck Lever
2026-05-22 19:42 ` [PATCH v5 06/21] nfsd: make nfsd4_callback_ops->prepare operation bool return Jeff Layton
2026-05-22 19:42 ` [PATCH v5 07/21] nfsd: add callback encoding and decoding linkages for CB_NOTIFY Jeff Layton
2026-06-08 16:52   ` Chuck Lever
2026-06-10 15:19     ` Jeff Layton
2026-06-10 15:25       ` Chuck Lever
2026-05-22 19:42 ` [PATCH v5 08/21] nfsd: use RCU to protect fi_deleg_file Jeff Layton
2026-06-08 17:00   ` Chuck Lever
2026-05-22 19:42 ` [PATCH v5 09/21] nfsd: add data structures for handling CB_NOTIFY Jeff Layton
2026-06-08 20:18   ` Chuck Lever
2026-06-10 15:51     ` Jeff Layton
2026-05-22 19:42 ` [PATCH v5 10/21] nfsd: add notification handlers for dir events Jeff Layton
2026-06-08 20:40   ` Chuck Lever
2026-06-10 18:33     ` Jeff Layton
2026-06-08 20:52   ` Chuck Lever
2026-06-10 18:38     ` Jeff Layton
2026-05-22 19:42 ` [PATCH v5 11/21] nfsd: add tracepoint to dir_event handler Jeff Layton
2026-05-22 19:42 ` [PATCH v5 12/21] nfsd: apply the notify mask to the delegation when requested Jeff Layton
2026-05-22 19:42 ` [PATCH v5 13/21] nfsd: add helper to marshal a fattr4 from completed args Jeff Layton
2026-05-22 19:42 ` [PATCH v5 14/21] nfsd: allow nfsd4_encode_fattr4_change() to work with no export Jeff Layton
2026-05-22 19:42 ` [PATCH v5 15/21] nfsd: send basic file attributes in CB_NOTIFY Jeff Layton
2026-05-22 19:42 ` [PATCH v5 16/21] nfsd: allow encoding a filehandle into fattr4 without a svc_fh Jeff Layton
2026-05-22 19:42 ` [PATCH v5 17/21] nfsd: add a fi_connectable flag to struct nfs4_file Jeff Layton
2026-05-22 19:42 ` [PATCH v5 18/21] nfsd: add the filehandle to returned attributes in CB_NOTIFY Jeff Layton
2026-05-22 19:42 ` [PATCH v5 19/21] nfsd: properly track requested child attributes Jeff Layton
2026-05-22 19:42 ` [PATCH v5 20/21] nfsd: track requested dir attributes Jeff Layton
2026-05-22 19:42 ` [PATCH v5 21/21] nfsd: add support to CB_NOTIFY for dir attribute changes Jeff Layton
2026-05-23 17:00 ` [PATCH v5 00/21] nfsd: add support for CB_NOTIFY callbacks in directory delegations Chuck Lever

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=dd5836b365946641824dbde5b6edc5395271617d.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=alex.aring@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=anna@kernel.org \
    --cc=brauner@kernel.org \
    --cc=calum.mackay@oracle.com \
    --cc=cel@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=corbet@lwn.net \
    --cc=jack@suse.cz \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=skhan@linuxfoundation.org \
    --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