Re: [PATCH net-next v15 01/12] vsock: add netns to vsock core

Bobby Eshleman
2026-01-21T17:36:51Z

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