Re: [PATCH v2 5/7] nfsd: keep polling a layout recall answered with NFS4ERR_OLD_STATEID

[Jeff Layton <jlayton@kernel.org>]

On Wed, 2026-10-14 at 07:06 -0400, Jeff Layton wrote:
> On Wed, 2026-10-14 at 16:30 +0900, Daejun Park via B4 Relay wrote:
> > From: Daejun Park <daejun7.park@samsung.com>
> > 
> > When a client answers CB_LAYOUTRECALL with NFS4_OK and still holds
> > layouts, nfsd4_cb_layout_done() sends the callback again after 10 ms to
> > see if the client is done. The repeat carries the stateid of the first
> > callback, although RFC 8881 section 12.5.3 has the server increment the
> > seqid in each CB_LAYOUTRECALL request.
> > 
> > The same section makes the seqid of a processed CB_LAYOUTRECALL the
> > current seqid of the client. Since commit dce72920c81b ("NFSv4.1: if
> > referring calls are complete, trust the stateid argument"), which is in
> > v6.8, the Linux client answers a recall whose seqid is not newer than
> > its own with NFS4ERR_OLD_STATEID, unless a LAYOUTRETURN is on the wire
> > (NFS4ERR_DELAY) or the layouts are gone (NFS4ERR_NOMATCHING_LAYOUT).
> > Before that commit it answered a repeat of the recall it was working
> > on with NFS4_OK until its LAYOUTRETURN was prepared, and with
> > NFS4ERR_OLD_STATEID from then until nfsd had processed the LAYOUTRETURN
> > (read from the code, not run). So a client from v6.8 on that needs
> > more than 10 ms to finish its I/O and to send LAYOUTRETURN answers the
> > second callback with NFS4ERR_OLD_STATEID, and an older client can
> > answer a later one that way.
> > 
> 
> What eventually breaks this cycle? The client has a newer layout, so it
> returns NFS4ERR_OLD_STATEID to the CB_LAYOUTRECALL, and now the server
> is going to continually retransmit that request. What makes the server
> eventually give up?
> 
> Or am I misunderstanding what causes this?
> 
> 

Oh, I think I see. The next patch makes it retransmit the
CB_LAYOUTRECALL with a more up-to-date stateid. That should eventually
resolve itself, I think.

It would make sense to squash 5 and 6 together so we don't end up with
this endless cycle if this happens on a bisect.
-- 
Jeff Layton <jlayton@kernel.org>