On 2/13/25 11:54 AM, Trond Myklebust wrote: > On Thu, 2025-02-13 at 11:15 -0500, cel@xxxxxxxxxx wrote: >> From: Chuck Lever <chuck.lever@xxxxxxxxxx> >> >> The NFSv4.2 protocol requires that a client match a CB_OFFLOAD >> callback to a COPY reply containing the same copy state ID. However, >> it's possible that the order of the callback and reply processing on >> the client can cause the CB_OFFLOAD to be received and processed >> /before/ the client has dealt with the COPY reply. >> >> Currently, in this case, the Linux NFS client will queue a fresh >> struct nfs4_copy_state in the CB_OFFLOAD handler. >> handle_async_copy() then checks for a matching nfs4_copy_state >> before settling down to wait for a CB_OFFLOAD reply. >> >> But it would be simpler for the client's callback service to respond >> to such a CB_OFFLOAD with "I'm not ready yet" and have the server >> send the CB_OFFLOAD again later. This avoids the need for the >> client's CB_OFFLOAD processing to allocate an extra struct >> nfs4_copy_state -- in most cases that allocation will be tossed >> immediately, and it's one less memory allocation that we have to >> worry about accidentally leaking or accumulating over time. > > Why can't the server just fill an appropriate entry for > csa_referring_call_lists<> in the CB_SEQUENCE operation for the > CB_OFFLOAD callback? That's the mechanism that is intended to be used > to avoid the above kind of race. Intriguing suggestion. It would be helpful if that were called out in RFC 7862. Should support for referring call lists be a requirement, then, for async COPY offload? I don't see a normative mandatory-to-implement statement for rcl's in RFC 8881, if that matters. Practically speaking, though, NFSD callback does not (yet) support referring call lists. It's been left as an exercise for some time. We simply haven't had a strong driver for it. Maybe we do now. -- Chuck Lever
