[PATCH net v3 0/3] vsock: add write-once semantics to child_ns_mode
From: Bobby Eshleman
Date: Mon Feb 23 2026 - 17:39:26 EST
Two administrator processes may race when setting child_ns_mode: one
sets it to "local" and creates a namespace, but another changes it to
"global" in between. The first process ends up with a namespace in the
wrong mode. Make child_ns_mode write-once so that a namespace manager
can set it once, check the value, and be guaranteed it won't change
before creating its namespaces. Writing a different value after the
first write returns -EBUSY.
One patch for the implementation, one for docs, and one for tests.
---
Changes in v3:
- Simplify code be reverting approach of using only a single variable to
represent both lock state and child_ns_mode state. Instead, use
child_ns_mode and child_ns_mode_locked.
- Update documentation to clarify the value-dependent behavior of
child_ns_mode writes (that is, same value is ok, different value gets
-EBUSY).
- fixed some line length > 80 checkpatch issues in vmtest.sh
- Link to v2: https://lore.kernel.org/r/20260218-vsock-ns-write-once-v2-0-19e4c50d509a@xxxxxxxx
Changes in v2:
- break docs, tests, and implementation into separate patches
- clarify commit message
- only use child_ns_mode, do not add additional child_ns_mode_locked
variable
- add documentation to Documentation/
- Link to v1: https://lore.kernel.org/r/20260217-vsock-ns-write-once-v1-1-a1fb30f289a9@xxxxxxxx
---
Bobby Eshleman (3):
selftests/vsock: change tests to respect write-once child ns mode
vsock: lock down child_ns_mode as write-once
vsock: document write-once behavior of the child_ns_mode sysctl
Documentation/admin-guide/sysctl/net.rst | 3 +++
include/net/af_vsock.h | 13 ++++++++--
include/net/netns/vsock.h | 3 +++
net/vmw_vsock/af_vsock.c | 15 ++++++++----
tools/testing/selftests/vsock/vmtest.sh | 41 ++++++++++++++++----------------
5 files changed, 48 insertions(+), 27 deletions(-)
---
base-commit: ccd8e87748ad083047d6c8544c5809b7f96cc8df
change-id: 20260217-vsock-ns-write-once-8834d684e0a2
Best regards,
--
Bobby Eshleman <bobbyeshleman@xxxxxxxx>