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
