[PATCH kernel] fix #8121: cherry-pick fix for hanging NFSv4.2 server-side copy

[PATCH kernel] fix #8121: cherry-pick fix for hanging NFSv4.2 server-side copy

[Lubos Rendek]

Since 7.0.14-20, an NFSv4.2 server-side copy between two exports of an
NFS server running our kernel never completes: nfsd sends the CB_OFFLOAD
callback with an all-zero stateid, so the client cannot match it to its
pending COPY and cp(1) waits forever, even though the data is already
complete on the server.

Caused by the stable backport of "nfsd: fix stale s2s_cp_stateids IDR
entry for async COPY", which came in with the Ubuntu stable updates.
This is the fix that went into upstream stable as 7.2.12 (8e42aeb5b39f)
and 6.18.58 (22732b0f290a), reviewed by Jeff Layton. It applies cleanly
on top of the current patch queue.

Signed-off-by: Lubos Rendek <l.rendek@proxmox.com>
---
Tested by building the patched queue (Ubuntu-7.0.0-43.43i1 plus all
patches including this one) with the 7.0.14-22-pve config, reduced with
localmodconfig, and booting it on a test node: an async NFSv4.2 COPY
between two exports completes and CB_OFFLOAD carries the same stateid as
the COPY reply (3 x 512 MiB plus 1 MiB, data identical, kernel untainted,
no nfsd messages). Without the fix, cp(1) hangs on 7.0.14-20 and
7.0.14-22. No full package build.

Upstream report and stable patches:
https://lore.kernel.org/stable/7cc824c4-632d-49df-ae5e-cfcbb5bf76ad@proxmox.com/

 ...o-stateid-in-CB_OFFLOAD-for-async-CO.patch | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 patches/kernel/0137-nfsd-fix-all-zero-stateid-in-CB_OFFLOAD-for-async-CO.patch

diff --git a/patches/kernel/0137-nfsd-fix-all-zero-stateid-in-CB_OFFLOAD-for-async-CO.patch b/patches/kernel/0137-nfsd-fix-all-zero-stateid-in-CB_OFFLOAD-for-async-CO.patch
new file mode 100644
index 0000000..864d3a1
--- /dev/null
+++ b/patches/kernel/0137-nfsd-fix-all-zero-stateid-in-CB_OFFLOAD-for-async-CO.patch
@@ -0,0 +1,52 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Lubos Rendek <l.rendek@proxmox.com>
+Date: Thu, 15 Oct 2026 11:53:40 +1100
+Subject: [PATCH] nfsd: fix all-zero stateid in CB_OFFLOAD for async COPY
+
+[ There is no upstream commit: this fixes the 7.2.y backport of
+  d0beaee498e1. Mainline fixed the problem as part of the async COPY
+  rework in commit f307b4f7ed17 ("nfsd: split nfsd4_copy into transient
+  and durable async copy objects"), which is too risky to backport. ]
+
+Since commit 14b978e8d05c ("nfsd: fix stale s2s_cp_stateids IDR entry
+for async COPY"), nfsd4_copy() calls dup_copy_fields() before the copy
+stateid is created and then writes the new stateid only into the COPY
+result. The async copy's own cp_res.cb_stateid stays zero, so
+nfsd4_send_cb_offload() sends CB_OFFLOAD with an all-zero stateid. The
+client cannot match it to its pending COPY and waits forever in
+nfs42_proc_copy().
+
+Also copy the new stateid into async_copy->cp_res.cb_stateid. Calling
+dup_copy_fields() after nfs4_init_copy_state() instead is not an
+option, because dup_copy_fields() also copies cp_stateid and would
+overwrite the stateid that the backport moved to the async copy.
+
+Tested on 7.2.10 with an NFSv4.2 server-side COPY between two
+exports: with this change the copy completes and CB_OFFLOAD carries
+the same stateid as the COPY reply. Without it, cp(1) hangs on 7.2.4
+and 7.2.9; the affected code in nfsd4_copy() is the same in 7.2.10.
+
+Fixes: 14b978e8d05c ("nfsd: fix stale s2s_cp_stateids IDR entry for async COPY")
+Closes: https://lore.kernel.org/stable/7cc824c4-632d-49df-ae5e-cfcbb5bf76ad@proxmox.com/
+Assisted-by: Claude:claude-opus-5-5
+Signed-off-by: Lubos Rendek <l.rendek@proxmox.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+(cherry picked from commit 8e42aeb5b39f721d086ce984b2af2ba2f7b77f94)
+Signed-off-by: Lubos Rendek <l.rendek@proxmox.com>
+---
+ fs/nfsd/nfs4proc.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
+index 8735acaa10e0aff417fb216ba3d2fca4289d1bc7..003f42a7fca84a4b444f3ecfad301556d6780691 100644
+--- a/fs/nfsd/nfs4proc.c
++++ b/fs/nfsd/nfs4proc.c
+@@ -2244,6 +2244,8 @@ nfsd4_copy(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
+ 			goto out_dec_async_copy_err;
+ 		memcpy(&result->cb_stateid, &async_copy->cp_stateid.cs_stid,
+ 			sizeof(result->cb_stateid));
++		memcpy(&async_copy->cp_res.cb_stateid, &async_copy->cp_stateid.cs_stid,
++		       sizeof(async_copy->cp_res.cb_stateid));
+ 		if ((READ_ONCE(copy->nf_dst->nf_file->f_mode) &
+ 			       FMODE_NOCMTIME) != 0)
+ 			async_copy->attr_update = true;
-- 
2.47.3

applied: [PATCH kernel] fix #8121: cherry-pick fix for hanging NFSv4.2 server-side copy

[Thomas Lamprecht]

On Wed, 04 Nov 2026 11:48:48 +1100, Lubos Rendek wrote:
> Since 7.0.14-20, an NFSv4.2 server-side copy between two exports of an
> NFS server running our kernel never completes: nfsd sends the CB_OFFLOAD
> callback with an all-zero stateid, so the client cannot match it to its
> pending COPY and cp(1) waits forever, even though the data is already
> complete on the server.
> 
> Caused by the stable backport of "nfsd: fix stale s2s_cp_stateids IDR
> entry for async COPY", which came in with the Ubuntu stable updates.
> This is the fix that went into upstream stable as 7.2.12 (8e42aeb5b39f)
> and 6.18.58 (22732b0f290a), reviewed by Jeff Layton. It applies cleanly
> on top of the current patch queue.
> 
> [...]

Applied, thanks!

[1/1] fix #8121: cherry-pick fix for hanging NFSv4.2 server-side copy
      commit: cbb54eb02d21de2d1d2777e1084161dc92fb38db