From: "Eric W. Biederman" <ebiederm@xmission•com>
To: David Laight <David.Laight@ACULAB•COM>
Cc: "Toke Høiland-Jørgensen" <toke@redhat•com>,
"David Ahern" <dsahern@gmail•com>,
"Stephen Hemminger" <stephen@networkplumber•org>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"Nicolas Dichtel" <nicolas.dichtel@6wind•com>,
"Christian Brauner" <brauner@kernel•org>
Subject: Re: [RFC PATCH iproute2-next 0/5] Persisting of mount namespaces along with network namespaces
Date: Tue, 10 Oct 2023 14:32:31 -0500 [thread overview]
Message-ID: <87edi2jmsw.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <6fc0ae94f5554c6ea320dba1d6fe84aa@AcuMS.aculab.com> (David Laight's message of "Tue, 10 Oct 2023 08:42:32 +0000")
David Laight <David.Laight@ACULAB•COM> writes:
> From: Eric W. Biederman
>> Sent: 09 October 2023 21:33
>>
>> 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.
>
> When I was getting a program to run in multiple network namespaces
> (has sockets in 2 namespaces) I rather expected that netns(net_ns_fd,0)
> would 'magically' change /proc/net to refer to the new namespace.
> I think that could be done in the code that follows the /proc/net
> mountpoint - IIRC something similar is done for /proc/self.
/proc/self/net does follow your current network namespace last I looked.
Of course if you are threaded you may need to look at
/proc/thread-self/net as your network namespace is per thread.
It is also quite evil. The problem is that having different entries
cached under the same name is a major mess. Ever since I made that
mistake I have been aiming at designs that don't fight the dcache.
Even in that case I think I limited it to just a entry where
ugliness happens.
> However that would need flags to both setns() and 'ip netns exec'
> since programs will rely on the existing behaviour.
You might want to look again.
Eric
next prev parent reply other threads:[~2023-10-10 20:11 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 ` [RFC PATCH iproute2-next 0/5] Persisting of mount namespaces along with network namespaces Eric W. Biederman
2023-10-09 22:03 ` 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 [this message]
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=87edi2jmsw.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