Hi,
On 12/2/25 11:01 PM, Bobby Eshleman wrote:
On Tue, Dec 02, 2025 at 09:47:19PM +0100, Paolo Abeni wrote:
I still have some concern WRT the dynamic mode change after netns creation. I fear some 'unsolvable' (or very hard to solve) race I can't see now. A tcp_child_ehash_entries-like model will avoid completely the issue, but I understand it would be a significant change over the current status.
"Luckily" the merge window is on us and we have some time to discuss. Do you have a specific use-case for the ability to change the netns mode after creation?
/P
I don't think there is a hard requirement that the mode be change-able after creation. Though I'd love to avoid such a big change... or at least leave unchanged as much of what we've already reviewed as possible.
In the scheme of defining the mode at creation and following the tcp_child_ehash_entries-ish model, what I'm imagining is:
/proc/sys/net/vsock/child_ns_mode can be set to "local" or "global"
/proc/sys/net/vsock/child_ns_mode is not immutable, can change any number of times
when a netns is created, the new netns mode is inherited from child_ns_mode, being assigned using something like:
net->vsock.ns_mode = get_net_ns_by_pid(current->pid)->child_ns_mode
/proc/sys/net/vsock/ns_mode queries the current mode, returning "local" or "global", returning value of net->vsock.ns_mode
/proc/sys/net/vsock/ns_mode and net->vsock.ns_mode are immutable and reject writes
Does that align with what you have in mind?
Sorry for the latency. This fell of my radar while I still processed PW before EoY and afterwards I had some break.
Yes, the above aligns with what I suggested, and I think it should solve possible race-related concerns (but I haven't looked at the RFC).
/P