On 1/22/25 10:44 AM, Jeff Layton wrote:
On Wed, 2025-01-22 at 10:20 -0500, Chuck Lever wrote:
On 1/22/25 10:10 AM, Jeff Layton wrote:
The v4.0 client always restarts the callback when the connection is shut
down (which is indicated by RPC_SIGNALLED()). The RPC is then requeued
and the result eventually should complete (or be aborted).
The v4.1 code instead processes the result and only later decides to
restart the call. Even more problematic is the fact that it releases the
slot beforehand. The restarted call may get a new slot, which would
could break DRC handling.
"break DRC handling" -- I'd like to understand this.
NFSD always sets cachethis to false in CB_SEQUENCE, so there is no DRC
for these operations. The only thing the client saves is the slot
sequence number IIUC.
Is retrying an uncached operation via a different slot a problem?
Ahh, I missed that we always set cachethis to false. So, there is
probably now a problem with the DRC after all. Still, I don't see a
good argument for processing the CB_SEQUENCE result, when we intend to
retransmit the call anyway.
I expect that the rationale is that the slot sequence number needs to be
advanced appropriately before the slot can be used again.
--
Chuck Lever
