From: "Eric W. Biederman" <ebiederm@xmission•com>
To: "Toke Høiland-Jørgensen" <toke@redhat•com>
Cc: David Ahern <dsahern@gmail•com>,
Stephen Hemminger <stephen@networkplumber•org>,
netdev@vger•kernel.org,
Nicolas Dichtel <nicolas.dichtel@6wind•com>,
Christian Brauner <brauner@kernel•org>,
David Laight <David.Laight@ACULAB•COM>
Subject: Re: [RFC PATCH iproute2-next 0/5] Persisting of mount namespaces along with network namespaces
Date: Mon, 09 Oct 2023 15:32:44 -0500 [thread overview]
Message-ID: <877cnvtu37.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20231009182753.851551-1-toke@redhat.com> ("Toke Høiland-Jørgensen"'s message of "Mon, 9 Oct 2023 20:27:48 +0200")
Toke Høiland-Jørgensen <toke@redhat•com> writes:
> The 'ip netns' command is used for setting up network namespaces with persistent
> named references, and is integrated into various other commands of iproute2 via
> the -n switch.
>
> This is useful both for testing setups and for simple script-based namespacing
> but has one drawback: the lack of persistent mounts inside the spawned
> namespace. This is particularly apparent when working with BPF programs that use
> pinning to bpffs: by default no bpffs is available inside a namespace, and
> even if mounting one, that fs disappears as soon as the calling
> command exits.
It would be entirely reasonable to copy mounts like /sys/fs/bpf from the
original mount namespace into the temporary mount namespace used by
"ip netns".
I would call it a bug that "ip netns" doesn't do that already.
I suspect that "ip netns" does copy the mounts from the old sysfs onto
the new sysfs is your entire problem.
Or is their a reason that bpffs should be per network namespace?
> The underlying cause for this is that iproute2 will create a new mount namespace
> every time it switches into a network namespace. This is needed to be able to
> mount a /sys filesystem that shows the correct network device information, but
> has the unfortunate side effect of making mounts entirely transient for any 'ip
> netns' invocation.
Mount propagation can be made to work if necessary, that would solve the
transient problem.
> This series is an attempt to fix this situation, by persisting a mount namespace
> alongside the persistent network namespace (in a separate directory,
> /run/netns-mnt). Doing this allows us to still have a consistent /sys inside
> the namespace, but with persistence so any mounts survive.
I really don't like that direction.
"ip netns" was designed and really should continue to be a command that
makes the world look like it has a single network namespace, for
compatibility with old code. Part of that old code "ip netns" supports
is "ip" itself.
I think you are making bpffs unnecessarily per network namespace.
> This mode does come with some caveats. I'm sending this as RFC to get feedback
> on whether this is the right thing to do, especially considering backwards
> compatibility. On balance, I think that the approach taken here of
> unconditionally persisting the mount namespace, and using that persistent
> reference whenever it exists, is better than the current behaviour, and that
> while it does represent a change in behaviour it is backwards compatible in a
> way that won't cause issues. But please do comment on this; see the patch
> description of patch 4 for details.
As I understand it this will cause a problem for any application that
is network namespace aware and does not use "ip netns" to wrap itself.
I am fairly certain that pinning the mount namespace will result in
never seeing an update of /etc/resolve.conf. At least if you
are on a system that has /etc/netns/NAME/resolve.conf
Unless I am missing something I think you are trying to solve the wrong
problem. I think all it will take is for the new mount of /sys to have
the same mounts on it as the previous mount of /sys.
Eric
next prev parent reply other threads:[~2023-10-09 20:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 18:27 [RFC PATCH iproute2-next 0/5] Persisting of mount namespaces along with network namespaces Toke Høiland-Jørgensen
2023-10-09 18:27 ` [RFC PATCH iproute2-next 1/5] ip: Mount netns in child process instead of from inside the new namespace Toke Høiland-Jørgensen
2023-10-09 18:27 ` [RFC PATCH iproute2-next 2/5] ip: Split out code creating namespace mount dir so it can be reused Toke Høiland-Jørgensen
2023-10-09 18:27 ` [RFC PATCH iproute2-next 3/5] lib/namespace: Factor out code for reuse Toke Høiland-Jørgensen
2023-10-09 18:27 ` [RFC PATCH iproute2-next 4/5] ip: Also create and persist mount namespace when creating netns Toke Høiland-Jørgensen
2023-10-09 18:27 ` [RFC PATCH iproute2-next 5/5] lib/namespace: Also mount a bpffs instance inside new mount namespaces Toke Høiland-Jørgensen
2023-10-09 20:32 ` Eric W. Biederman [this message]
2023-10-09 22:03 ` [RFC PATCH iproute2-next 0/5] Persisting of mount namespaces along with network namespaces Toke Høiland-Jørgensen
2023-10-10 0:14 ` Eric W. Biederman
2023-10-10 13:38 ` Toke Høiland-Jørgensen
2023-10-10 19:19 ` Eric W. Biederman
2023-10-11 13:49 ` Toke Høiland-Jørgensen
2023-10-11 14:55 ` Eric W. Biederman
2023-10-11 15:03 ` Toke Høiland-Jørgensen
2023-10-10 8:42 ` David Laight
2023-10-10 19:32 ` Eric W. Biederman
2023-10-10 21:51 ` David Laight
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=877cnvtu37.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission$(echo .)com \
--cc=David.Laight@ACULAB$(echo .)COM \
--cc=brauner@kernel$(echo .)org \
--cc=dsahern@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nicolas.dichtel@6wind$(echo .)com \
--cc=stephen@networkplumber$(echo .)org \
--cc=toke@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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