From: Chuck Lever <cel@kernel.org>
To: NeilBrown <neil@brown.name>, Jeff Layton <jlayton@kernel.org>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: <linux-nfs@vger.kernel.org>
Subject: [PATCH 0/4] Confine the inter-server copy interface to fs/nfs_common
Date: Tue, 21 Jul 2026 12:23:02 -0400 [thread overview]
Message-ID: <20260721162306.894558-1-cel@kernel.org> (raw)
Inter-server copy has drawn a steady trail of use-after-free and
reference-leak fixes: 75333d48f922, 34e8f9ec4c9a, and d2c343c51caf
among them. They cluster on one object, the source mount that the NFS
client creates and opens while NFSD decides when it may be torn down.
The bookkeeping that tracks it, added by f4e44b393389, has needed
three follow-on repairs of its own. Splitting an object's lifetime
across two modules that are forbidden to call each other directly is
what keeps producing these bugs.
The fix in 75333d48f922 narrowed that split rather than adding
another rule to it. NFSD stopped reaching back through the broker to
deactivate the source superblock, and post-copy clean-up became the
laundromat's business alone. What the fix did not do was retract the
interface it had just stopped using, so the client-side registration
machinery has sat unused since (patch 1).
One implicit contract between the two modules is still in force.
Reading the client ops table without synchronization is safe
only for reasons that live on the caller's side: an inter-server copy
holds an active vers=4.2 mount of the source, that mount pins the
nfsv4 module, and unregister runs only at module exit. Patch 3
replaces that with synchronization the broker owns, so the argument
no longer depends on how a caller in another subsystem manages
mounts.
What remains after that is textual. The header still declares both
sides' interfaces, so each implementation parses the other's types
and inherits its includes, which is how <uapi/linux/nfs.h> reaches
nfs4proc.c. Once the knowledge only NFSD holds has moved into the
broker, splitting that header is mechanical.
None of this fixes a live bug, and the source mount's lifetime still
spans both modules. What changes is that the broker no longer relies
on rules its callers enforce. Inter-server copy behavior is meant to
be unchanged throughout.
Chuck Lever (4):
nfs_common: Remove unused nfs_ssc_client_ops infrastructure
NFSD: Hoist nfs42_ssc_open() into fs/nfs_common/nfs_ssc.c
nfs_common: Synchronize access to the SSC client ops table
NFSD: Split linux/nfs_ssc.h
fs/nfs/nfs4file.c | 1 +
fs/nfs/super.c | 25 --------
fs/nfs_common/nfs_ssc.c | 126 ++++++++++++++++++++++++---------------
fs/nfsd/nfs4proc.c | 22 ++-----
fs/nfsd/nfs4state.c | 2 +-
fs/nfsd/xdr4.h | 13 ++++
include/linux/nfs_ssc.h | 69 ++++-----------------
include/linux/nfsd_ssc.h | 38 ++++++++++++
8 files changed, 147 insertions(+), 149 deletions(-)
create mode 100644 include/linux/nfsd_ssc.h
--
2.54.0
next reply other threads:[~2026-07-21 16:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 16:23 Chuck Lever [this message]
2026-07-21 16:23 ` [PATCH 1/4] nfs_common: Remove unused nfs_ssc_client_ops infrastructure Chuck Lever
2026-07-21 16:23 ` [PATCH 2/4] NFSD: Hoist nfs42_ssc_open() into fs/nfs_common/nfs_ssc.c Chuck Lever
2026-07-21 16:23 ` [PATCH 3/4] nfs_common: Synchronize access to the SSC client ops table Chuck Lever
2026-07-21 16:23 ` [PATCH 4/4] NFSD: Split linux/nfs_ssc.h Chuck Lever
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=20260721162306.894558-1-cel@kernel.org \
--to=cel@kernel.org \
--cc=dai.ngo@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
/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.