summaryrefslogtreecommitdiff
path: root/scripts
diff options
context:
space:
mode:
authorChuck Lever <cel@kernel.org>2026-08-02 13:04:36 -0400
committerChuck Lever <cel@kernel.org>2026-08-26 16:41:51 -0400
commit4492ec6caa95b1604b97f3154ec503baeebdbdfd (patch)
tree33db06b7f7218f1dc2922b41ca1dcf694fb99db7 /scripts
parent2049c5ec11fa5bfc1f217bab8c200013897f55f2 (diff)
downloadlinux-next-4492ec6caa95b1604b97f3154ec503baeebdbdfd.tar.gz
linux-next-4492ec6caa95b1604b97f3154ec503baeebdbdfd.zip
NFSD: Send referring calls with CB_RECALL
When CB_RECALL races ahead of the reply that granted the delegation, the client has not yet recorded the delegation stateid and responds NFS4ERR_BADHANDLE or NFS4ERR_BAD_STATEID. The slot that carried the grant has not retired at that point, so NFSD cannot read the rejection as proof that the client never held the delegation. It retries the recall and, once the retries lapse, revokes a delegation the client is by then able to return. Remove the ambiguity with the referring call mechanism of RFC 8881 Section 2.10.6.3: until the slot that carried the grant retires, name that request as a referring call in the CB_SEQUENCE of each recall. A client that finds it still outstanding may respond NFS4ERR_DELAY, and the recall is retried until the client has processed the grant. A recall reuses one callback context across its retries, and ->prepare does not run on every send. The granting request does not change, so a send that inherits the previous list sends the right one. Retirement of the granting slot drops the list, and nfs4_free_deleg() releases what is left. Link: https://patch.msgid.link/20260802-nfsd-deleg-destroy-badhandle-v1-9-323aa7196055@kernel.org Signed-off-by: Chuck Lever <cel@kernel.org>
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions