On Wed, Jan 21, 2026 at 05:32:34PM +0100, Paolo Abeni wrote: > On 1/21/26 3:48 PM, Stefano Garzarella wrote: > >> diff --git a/Documentation/admin-guide/kernel-parameters.txt > >> b/Documentation/admin-guide/kernel-parameters.txt > >> index a8d0afde7f85..b6e3bfe365a1 100644 > >> --- a/Documentation/admin-guide/kernel-parameters.txt > >> +++ b/Documentation/admin-guide/kernel-parameters.txt > >> @@ -8253,6 +8253,20 @@ Kernel parameters > >> them quite hard to use for exploits but > >> might break your system. > >> > >> + vsock_init_ns_mode= > >> + [KNL,NET] Set the vsock namespace mode for the init > >> + (root) network namespace. > >> + > >> + global [default] The init namespace operates in > >> + global mode where CIDs are system-wide and > >> + sockets can communicate across global > >> + namespaces. > >> + > >> + local The init namespace operates in local mode > >> + where CIDs are private to the namespace and > >> + sockets can only communicate within the same > >> + namespace. > >> + > > > > My comment on v14 was more to start a discussion :-) sorry to not be > > clear. > > > > I briefly discussed it with Paolo in chat to better understand our > > policy between cmdline parameters and module parameters, and it seems > > that both are discouraged. > > Double checking the git log it looks like __setup() usage is less > constrained/restricted than what I thought. > > > So he asked me if we have a use case for this, and thinking about it, I > > don't have one at the moment. Also, if a user decides to set all netns > > to local, whether init_net is local or global doesn't really matter, > > right? > > > > So perhaps before adding this, we should have a real use case. > > Perhaps more than this feature, I would add a way to change the default > > of all netns (including init_net) from global to local. But we can do > > that later, since all netns have a way to understand what mode they are > > in, so we don't break anything and the user has to explicitly change it, > > knowing that they are breaking compatibility with pre-netns support.\ > > Lacking a clear use-case for vsock_init_ns_mode I tend to think it would > be better to postpone its introduction. It should be easier to add it > later than vice-versa. > > If there is a clear/well defined/known use-case, I guess the series can > go as-is. > > /P >
Our use case also does not need the ability to set the init ns mode, so I'll revert this bit. Thanks, Bobby
