From: Jeff Layton <jlayton@kernel.org>
To: Cedric Blancher <cedric.blancher@gmail.com>,
Chuck Lever <cel@kernel.org>,
"ms-nfs41-client-devel@lists.sourceforge.net"
<Ms-nfs41-client-devel@lists.sourceforge.net>
Cc: NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH 4/4] NFSD: Send a meaningful CB_RECALL_ANY keep count
Date: Wed, 12 Aug 2026 06:29:49 -0400 [thread overview]
Message-ID: <dece989f5e1df1343713183f068fcb6d8c63ddbf.camel@kernel.org> (raw)
In-Reply-To: <CALXu0UeKoYPq0FOGe2vQP2p9txTzEkscc10hy4Lw_S6=wK1a3Q@mail.gmail.com>
On Wed, 2026-08-12 at 08:17 +0200, Cedric Blancher wrote:
> On Tue, 11 Aug 2026 at 21:57, Chuck Lever <cel@kernel.org> wrote:
> >
> > deleg_reaper() sets craa_objects_to_keep to zero on every
> > CB_RECALL_ANY. Per RFC 8881 Section 20.6.3, that asks the client to
> > retain no read or write delegation at all, whether or not the
> > delegation backs an open file.
> >
> > The field names a count the client may keep. The client picks which
> > objects to return, because the server cannot read lack of recent
> > use as lack of usefulness. Zero leaves nothing to choose among. A
> > client that complies returns the delegations backing its open files
> > and reopens each one with CLAIM_DELEGATE_CUR, so NFSD trades a
> > delegation for an open stateid and recovers nothing. A client that
> > reads the zero as "unspecified" does nothing instead, and
> > nfsd4_cb_recall_any_done() inspects only the reply status, so NFSD
> > cannot tell the two apart.
> >
> > Derive the keep count from cl_deleg_count and ask each client for a
> > single delegation. A larger request reaches delegations an
> > application still has open, and both callers re-arm while their
> > condition lasts. Skip a client holding one delegation rather than
> > send the zero again. That gate subsumes the list_empty() test above
> > it, and it belongs above the NFSD4_CALLBACK_RUNNING test_and_set. A
> > continue below that point latches the bit with no callback in
> > flight to clear it.
> >
> > The Linux client ignores craa_objs_to_keep and returns unused
> > delegations from the type mask alone, so the count changes nothing
> > for it. The gate does. The reaper goes quiet for a client walked
> > down to one delegation.
> >
> > Fixes: 44df6f439a17 ("NFSD: add delegation reaper to react to low memory condition")
> > Signed-off-by: Chuck Lever <cel@kernel.org>
>
> ms-nfs41-client hit that bug when implementing CB_RECALL_ANY
> (https://github.com/kofemann/ms-nfs41-client/commit/3abe73c8ab0d924450a1c1c480f0b14f963f9531)
> with Linux 7.0 nfsd.
> What should existing NFSv4.1 clients do if they encounter a
> objects_to_keep value of 0? Right now it recalls ALL delegations,
> which basically is a "reset" of all delegations.
>
>
Like Chuck quotes above:
"Per RFC 8881 Section 20.6.3, that asks the client to retain no read or
write delegation at all, whether or not the delegation backs an open
file."
I think a compliant client would need to continue to return everything.
We should note that the Linux client apparently ignores
craa_objects_to_keep and just returns a single delegation, so you could
follow suit (but know that it's not following the spec).
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2026-08-12 10:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 19:52 [PATCH 0/4] NFSD: CB_RECALL_ANY fixes and a meaningful keep count Chuck Lever
2026-08-11 19:52 ` [PATCH 1/4] NFSD: Do not send CB_RECALL_ANY to NFSv4.0 clients Chuck Lever
2026-08-11 19:52 ` [PATCH 2/4] NFSD: Count the delegations held by each client Chuck Lever
2026-08-11 19:52 ` [PATCH 3/4] NFSD: Name directory delegations in the CB_RECALL_ANY type mask Chuck Lever
2026-08-11 19:52 ` [PATCH 4/4] NFSD: Send a meaningful CB_RECALL_ANY keep count Chuck Lever
2026-08-12 6:17 ` Cedric Blancher
2026-08-12 10:29 ` Jeff Layton [this message]
2026-08-12 14:02 ` Chuck Lever
2026-08-12 10:26 ` [PATCH 0/4] NFSD: CB_RECALL_ANY fixes and a meaningful " 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=dece989f5e1df1343713183f068fcb6d8c63ddbf.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=Ms-nfs41-client-devel@lists.sourceforge.net \
--cc=cedric.blancher@gmail.com \
--cc=cel@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.