diff options
| author | Chuck Lever <cel@kernel.org> | 2026-08-02 13:04:36 -0400 |
|---|---|---|
| committer | Chuck Lever <cel@kernel.org> | 2026-08-26 16:41:51 -0400 |
| commit | 4492ec6caa95b1604b97f3154ec503baeebdbdfd (patch) | |
| tree | 33db06b7f7218f1dc2922b41ca1dcf694fb99db7 /scripts | |
| parent | 2049c5ec11fa5bfc1f217bab8c200013897f55f2 (diff) | |
| download | linux-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
