Date:	Mon, 25 Aug 2014 07:04:28 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	nicolas.dichtel@...nd.com
Cc:	Linux Containers <containers@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-audit@...hat.com, Linux API <linux-api@...r.kernel.org>,
	Richard Guy Briggs <rgb@...hat.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH V4 3/8] namespaces: expose ns instance serial numbers in proc

On Aug 25, 2014 6:30 AM, "Nicolas Dichtel" <nicolas.dichtel@...nd.com> wrote:
>> CRIU wants to save the complete state of a namespace and then restore
>> it.  For that to work, any information exposed to things in the
>> namespace *cannot* be globally unique or unique per boot, since CRIU
>> needs to arrange for that information to match whatever it was when
>> CRIU saved it.
>
> How are ifindex of network devices managed? These ifindexes are unique per boot,
> thus can change depending on the order in which netdev are created.
> These ifindexes are unique per boot and exposed to userspace ...
>

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
    link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
    link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

>
>>
>> Also, I think that code running in a namespace has no business even
>> knowing a unique identity of that namespace from the perspective of
>> the host.
>
> Another scenario is when you have virtual network devices across two netns. You
> need to identify the peer netns to have a netlink message which is fully interpretable by the userspace.

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even
knowing a unique identity of *that namespace* from the perspective of
the host.

In your example, if there's a veth device between netns A and netns B,
then code *in netns A* has no business knowing the identity of its
veth peer if its peer (B) is a sibling or ancestor.  It also IMO has
no business knowing the identity of its own netns (A) other than as
"my netns".

If A and B are siblings, then their parent needs to know where that
veth device goes, but I think this is already the case to a sufficient
extent today.

I feel like this discussion is falling into a common trap of new API
discussions.  Can one of you who wants this API please articulate,
with a reasonably precise example, what it is that you want to do, why
you can't easily do it already, and how this API helps?  I currently
understand how the API creates problems, but I don't understand how it
solves any problems, and I will NAK it (and I suspect that Eric will,
too, which is pretty much fatal) unless that changes.

Thanks,
Andy

>
>
> Regards,
> Nicolas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists