netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
To: Christian Brauner <brauner@kernel.org>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"David Ahern" <dsahern@kernel.org>
Subject: Re: Persisting mounts between 'ip netns' invocations
Date: Fri, 29 Sep 2023 11:45:42 +0200	[thread overview]
Message-ID: <0a70d4fb-b790-cd7f-a0cd-ad38e978b0e9@6wind.com> (raw)
In-Reply-To: <20230929-paket-pechschwarz-a259da786431@brauner>

Le 29/09/2023 à 11:25, Christian Brauner a écrit :
>> I fear that creating a new mount ns for each net ns will introduce more problems.
> 
> Not sure if we're talking past each other but that is what's happening
> now. Each new ip netns exec invocation will allocate a _new_ mount
> namespace. In other words, if you have 300 ip netns exec commands
> running then there will be 300 individual mount namespaces active.
> 
> What I tried to say is that ip netns exec could be changed to
> _optionally_ allocate a prepared mount namespace that is shared between
> ip netns exec commands. And yeah, that would need to be a new command
> line addition to ip netns exec.

Ok, you talked about changing 'ip netns exec', not adding an option, thus I
thought that you suggested adding this unconditionally ;-)

I was asking myself how to propagate mount points between the parent and 'ip
netns exec' (both way), but this may be another use case than Toke's use case.


Regards,
Nicolas

  reply	other threads:[~2023-09-29  9:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28  8:29 Persisting mounts between 'ip netns' invocations Toke Høiland-Jørgensen
2023-09-28  9:54 ` Nicolas Dichtel
2023-09-28 16:17   ` Christian Brauner
2023-09-28 18:21     ` Toke Høiland-Jørgensen
2023-09-29  8:26       ` Nicolas Dichtel
2023-09-29  9:25         ` Christian Brauner
2023-09-29  9:45           ` Nicolas Dichtel [this message]
2023-09-29 21:23             ` David Laight
2023-09-29 15:00   ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0a70d4fb-b790-cd7f-a0cd-ad38e978b0e9@6wind.com \
    --to=nicolas.dichtel@6wind.com \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=dsahern@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=netdev@vger.kernel.org \
    --cc=toke@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).