diff options
author | Chuck Lever <chuck.lever@oracle.com> | 2024-10-31 16:40:04 +0300 |
---|---|---|
committer | Chuck Lever <chuck.lever@oracle.com> | 2024-11-19 04:23:10 +0300 |
commit | 409d6f52bd6b4fb43fbb4db9daeb5022e2e1d00c (patch) | |
tree | 4b26fda98c114338ba79863e15ce6e4d18e68f27 /rust/kernel/alloc/allocator_test.rs | |
parent | 62a8642ba00aa8ceb0a02ade942f5ec52e877c95 (diff) | |
download | linux-409d6f52bd6b4fb43fbb4db9daeb5022e2e1d00c.tar.xz |
NFSD: Free async copy information in nfsd4_cb_offload_release()
RFC 7862 Section 4.8 states:
> A copy offload stateid will be valid until either (A) the client
> or server restarts or (B) the client returns the resource by
> issuing an OFFLOAD_CANCEL operation or the client replies to a
> CB_OFFLOAD operation.
Currently, NFSD purges the metadata for an async COPY operation as
soon as the CB_OFFLOAD callback has been sent. It does not wait even
for the client's CB_OFFLOAD response, as the paragraph above
suggests that it should.
This makes the OFFLOAD_STATUS operation ineffective during the
window between the completion of an asynchronous COPY and the
server's receipt of the corresponding CB_OFFLOAD response. This is
important if, for example, the client responds with NFS4ERR_DELAY,
or the transport is lost before the server receives the response. A
client might use OFFLOAD_STATUS to query the server about the still
pending asynchronous COPY, but NFSD will respond to OFFLOAD_STATUS
as if it had never heard of the presented copy stateid.
This patch starts to address this issue by extending the lifetime of
struct nfsd4_copy at least until the server has seen the client's
CB_OFFLOAD response, or the CB_OFFLOAD has timed out.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to 'rust/kernel/alloc/allocator_test.rs')
0 files changed, 0 insertions, 0 deletions