All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Sasha Levin <sashal@kernel.org>, stable@vger.kernel.org
Cc: Chuck Lever <cel@kernel.org>, Jeff Layton <jlayton@kernel.org>,
	linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
	Lubos Rendek <l.rendek@proxmox.com>,
	regressions@lists.linux.dev
Subject: Re: [REGRESSION] 7.2.4: nfsd sends CB_OFFLOAD with all-zero stateid, async NFSv4.2 COPY never completes
Date: Mon, 12 Oct 2026 11:36:07 +0200	[thread overview]
Message-ID: <1791797151.oll70jtyaa.astroid@yuna.none> (raw)
In-Reply-To: <2026-10-11-1-daily-reply-0001-nfsd-cb-offload-zero-stateid@kernel.org>

On October 11, 2026 6:48 pm, Sasha Levin wrote:
>> Since 7.2.4, an NFSv4.2 server-side COPY between two exports of a Linux
>> NFS server never completes, because nfsd sends CB_OFFLOAD with an
>> all-zero stateid.
> 
> Queued the fix for 7.2 and 6.18, thanks.

AFAICT (for 7.2.x) you queued a full pick of

f307b4f7ed17 nfsd: split nfsd4_copy into transient and durable async copy objects

in

0b2963340727 nfsd: split nfsd4_copy into transient and durable async copy objects

despite Jeff stating the following up-thread:

> We should probably just take Lubos' two-line fix as a separate one-off
> patch for stable. Backporting the COPY code refactor is too risky IMO.

Was this intentional, or an accident?

FWIW, the full refactor would include two more patches:

d6edc2a72513efce59eaf85acb204d2ddac71892 nfsd: drop dead COPY-vs-COPYNOTIFY type handling from s2s stateid IDR
80c376183411300b4c99977c66f3f84f64b38676 nfsd: make the copy offload stateid a first-class nfs4_stid

so this is kind of half-way between the discussed options..

Fabian


  reply	other threads:[~2026-10-12  9:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-10 19:30 [REGRESSION] 7.2.4: nfsd sends CB_OFFLOAD with all-zero stateid, async NFSv4.2 COPY never completes Lubos Rendek
2026-10-11  7:19 ` Greg KH
2026-10-11 12:07   ` Jeff Layton
2026-10-11 20:33   ` Lubos Rendek
2026-10-11 16:48 ` Sasha Levin
2026-10-12  9:36   ` Fabian Grünbichler [this message]
2026-10-12 14:59     ` Sasha Levin
2026-10-13 10:15       ` Jeff Layton
2026-10-13 19:45         ` Lubos Rendek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1791797151.oll70jtyaa.astroid@yuna.none \
    --to=f.gruenbichler@proxmox.com \
    --cc=cel@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=l.rendek@proxmox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.