From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <cel@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Chuck Lever <chuck.lever@oracle.com>,
Alexander Aring <alex.aring@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
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>,
Amir Goldstein <amir73il@gmail.com>
Cc: Calum Mackay <calum.mackay@oracle.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH 12/24] nfsd: add data structures for handling CB_NOTIFY
Date: Wed, 08 Apr 2026 15:53:11 -0400 [thread overview]
Message-ID: <411738fab73b3625e0e4728e2749a24bfadb1773.camel@kernel.org> (raw)
In-Reply-To: <8a6dbbee-5d59-4833-b0f6-22b1e46dfd11@app.fastmail.com>
On Wed, 2026-04-08 at 14:39 -0400, Chuck Lever wrote:
> On Tue, Apr 7, 2026, at 9:21 AM, Jeff Layton wrote:
> > Add the data structures, allocation helpers, and callback operations
> > needed for directory delegation CB_NOTIFY support:
> >
> > - struct nfsd_notify_event: carries fsnotify events for CB_NOTIFY
> > - struct nfsd4_cb_notify: per-delegation state for notification handling
> > - Union dl_cb_fattr with dl_cb_notify in nfs4_delegation since a
> > delegation is either a regular file delegation or a directory
> > delegation, never both
> >
> > Refactor alloc_init_deleg() into a common __alloc_init_deleg() base
> > with a pluggable sc_free callback, and add alloc_init_dir_deleg() which
> > allocates the page array and notify4 buffer needed for CB_NOTIFY
> > encoding.
> >
> > Add skeleton nfsd4_cb_notify_ops with done/release handlers that will
> > be filled in when the notification path is wired up.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
>
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index 4afe7e68fb51..b2b8c454fc0f 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
>
> > @@ -3381,6 +3440,30 @@ nfsd4_cb_getattr_release(struct nfsd4_callback
> > *cb)
> > nfs4_put_stid(&dp->dl_stid);
> > }
> >
> > +static int
> > +nfsd4_cb_notify_done(struct nfsd4_callback *cb,
> > + struct rpc_task *task)
> > +{
> > + switch (task->tk_status) {
> > + case -NFS4ERR_DELAY:
> > + rpc_delay(task, 2 * HZ);
> > + return 0;
> > + default:
> > + return 1;
> > + }
> > +}
> > +
> > +static void
> > +nfsd4_cb_notify_release(struct nfsd4_callback *cb)
> > +{
> > + struct nfsd4_cb_notify *ncn =
> > + container_of(cb, struct nfsd4_cb_notify, ncn_cb);
> > + struct nfs4_delegation *dp =
> > + container_of(ncn, struct nfs4_delegation, dl_cb_notify);
> > +
> > + nfs4_put_stid(&dp->dl_stid);
> > +}
> > +
> > static const struct nfsd4_callback_ops nfsd4_cb_recall_any_ops = {
> > .done = nfsd4_cb_recall_any_done,
> > .release = nfsd4_cb_recall_any_release,
>
> So when a client responds with NFS4ERR_DELAY, the RPC framework retries
> after 2s. On retry, prepare() is called again, but ncn_evt_cnt is
> already 0 (drained in the first prepare). prepare returns false, which
> destroys the callback.
>
This is actually not a problem. When ->done() returns 0,
rpc_restart_call_prepare retries the RPC through the RPC-level prepare
(nfsd4_cb_prepare at nfs4callback.c:1479), which just acquires a
session slot and calls rpc_call_start. It does not call cb_ops->prepare
again — the same encoded XDR is re-sent in that case.
> Events arriving during the retry window are dropped because
> nfsd4_run_cb_notify() returns early when NFSD4_CALLBACK_RUNNING is set.
> After the callback is destroyed, future events can queue a new CB_NOTIFY,
> but the window's events are lost.
>
> The result is that the client misses notifications. Does this impact
> behavioral correctness or spec compliance? Is there a way for that
> client to detect the loss and recover?
>
There _is_ a problem, however. Events that arrive while the job is
running queue up, but won't get sent until the _next_ event arrives. We
need to make the ->release handler check for new events and requeue the
callback if there are any. I'll plan to fix that up.
Thanks for all the review! I'll plan to send another version soon (but
probably not until after next week's testing event).
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2026-04-08 19:53 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 13:21 [PATCH 00/24] vfs/nfsd: add support for CB_NOTIFY callbacks in directory delegations Jeff Layton
2026-04-07 13:21 ` [PATCH 01/24] filelock: add support for ignoring deleg breaks for dir change events Jeff Layton
2026-04-08 13:45 ` Jan Kara
2026-04-08 14:29 ` Jeff Layton
2026-04-08 18:16 ` Chuck Lever
2026-04-08 19:25 ` Jeff Layton
2026-04-07 13:21 ` [PATCH 02/24] filelock: add a tracepoint to start of break_lease() Jeff Layton
2026-04-08 13:45 ` Jan Kara
2026-04-07 13:21 ` [PATCH 03/24] filelock: add an inode_lease_ignore_mask helper Jeff Layton
2026-04-08 13:53 ` Jan Kara
2026-04-07 13:21 ` [PATCH 04/24] nfsd: add protocol support for CB_NOTIFY Jeff Layton
2026-04-07 13:21 ` [PATCH 05/24] nfs_common: add new NOTIFY4_* flags proposed in RFC8881bis Jeff Layton
2026-04-07 13:21 ` [PATCH 06/24] nfsd: allow nfsd to get a dir lease with an ignore mask Jeff Layton
2026-04-07 13:21 ` [PATCH 07/24] vfs: add fsnotify_modify_mark_mask() Jeff Layton
2026-04-08 13:51 ` Jan Kara
2026-04-07 13:21 ` [PATCH 08/24] nfsd: update the fsnotify mark when setting or removing a dir delegation Jeff Layton
2026-04-08 13:53 ` Jan Kara
2026-04-08 18:24 ` Chuck Lever
2026-04-08 19:29 ` Jeff Layton
2026-04-07 13:21 ` [PATCH 09/24] nfsd: make nfsd4_callback_ops->prepare operation bool return Jeff Layton
2026-04-07 13:21 ` [PATCH 10/24] nfsd: add callback encoding and decoding linkages for CB_NOTIFY Jeff Layton
2026-04-07 13:21 ` [PATCH 11/24] nfsd: use RCU to protect fi_deleg_file Jeff Layton
2026-04-07 13:21 ` [PATCH 12/24] nfsd: add data structures for handling CB_NOTIFY Jeff Layton
2026-04-08 18:39 ` Chuck Lever
2026-04-08 19:53 ` Jeff Layton [this message]
2026-04-07 13:21 ` [PATCH 13/24] nfsd: add notification handlers for dir events Jeff Layton
2026-04-08 18:34 ` Chuck Lever
2026-04-08 19:40 ` Jeff Layton
2026-04-07 13:21 ` [PATCH 14/24] nfsd: add tracepoint to dir_event handler Jeff Layton
2026-04-08 0:41 ` Steven Rostedt
2026-04-07 13:21 ` [PATCH 15/24] nfsd: apply the notify mask to the delegation when requested Jeff Layton
2026-04-07 13:21 ` [PATCH 16/24] nfsd: add helper to marshal a fattr4 from completed args Jeff Layton
2026-04-07 13:21 ` [PATCH 17/24] nfsd: allow nfsd4_encode_fattr4_change() to work with no export Jeff Layton
2026-04-07 13:21 ` [PATCH 18/24] nfsd: send basic file attributes in CB_NOTIFY Jeff Layton
2026-04-07 13:21 ` [PATCH 19/24] nfsd: allow encoding a filehandle into fattr4 without a svc_fh Jeff Layton
2026-04-07 13:21 ` [PATCH 20/24] nfsd: add a fi_connectable flag to struct nfs4_file Jeff Layton
2026-04-07 13:21 ` [PATCH 21/24] nfsd: add the filehandle to returned attributes in CB_NOTIFY Jeff Layton
2026-04-07 13:21 ` [PATCH 22/24] nfsd: properly track requested child attributes Jeff Layton
2026-04-07 13:21 ` [PATCH 23/24] nfsd: track requested dir attributes Jeff Layton
2026-04-07 13:21 ` [PATCH 24/24] nfsd: add support to CB_NOTIFY for dir attribute changes Jeff Layton
2026-04-08 13:55 ` [PATCH 00/24] vfs/nfsd: add support for CB_NOTIFY callbacks in directory delegations Jan Kara
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=411738fab73b3625e0e4728e2749a24bfadb1773.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-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@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