[PATCH v2 0/4] NFSD: CB_RECALL_ANY fixes and a meaningful keep count

NFSD sends every CB_RECALL_ANY with craa_objects_to_keep set to
zero, as RFC 8881 Section 20.6.3 does not mandate any particular
way for a client to choose which delegations to choose, if any.

However, a zero value can result in some clients giving back more
delegations than is necessary to relieve temporary memory pressure
on the server, which needlessly impacts performance.

NFSD intends the callback as a signal to return unused delegations.
Only the Linux client has been tested against it, and that client
ignores craa_objects_to_keep and returns only one unused delegation
of the named types, so the fixed zero never produced visible
misbehavior during our testing.

So, change NFSD so that each CB_RECALL_ANY asks a client to give up
one delegation. Both reaper callers (the shrinker to relieve memory
pressure, and the laundromat to cap the total number of delegations
the server tracks) re-arm while their condition lasts.

NFSD sets no recall target and remembers nothing across CB_RECALL_ANY
callbacks. RFC 8881 Section 20.6.4 prescribes the use of CB_RECALL
to target specific delegations if a client fails to return any. NFSD
does not take that step yet. CB_RECALL_ANY is asynchronous and
reports no completion, so NFSD treats it as advisory.

---
Changes in v2:
- Drop the gate that skipped clients holding a single delegation.
- Cover letter rewritten to give performance rationale.
- Link to v1: https://patch.msgid.link/[email protected]

---
Chuck Lever (4):
      NFSD: Do not send CB_RECALL_ANY to NFSv4.0 clients
      NFSD: Count the delegations held by each client
      NFSD: Name directory delegations in the CB_RECALL_ANY type mask
      NFSD: Send a meaningful CB_RECALL_ANY keep count

 fs/nfsd/nfs4state.c | 27 +++++++++++++++++++++++----
 fs/nfsd/state.h     |  2 ++
 2 files changed, 25 insertions(+), 4 deletions(-)
---
base-commit: 1d479c6b53f684b27da84ec352b7efb97f7f115f
change-id: 20260810-recall-any-keep-count-f50c2ae1b792

Best regards,
--  
Chuck Lever <[email protected]>