netdev - Re: [PATCH net-next v2 0/7] netns: ease netlink use with a lot of netns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 May 2015 15:09:54 +0200
From:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:	Alexander Holler <holler@...oftware.de>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	netdev@...r.kernel.org, tgraf@...g.ch, davem@...emloft.net
Subject: Re: [PATCH net-next v2 0/7] netns: ease netlink use with a lot of
 netns

Le 25/05/2015 12:55, Alexander Holler a écrit :
> Am 25.05.2015 um 09:45 schrieb Nicolas Dichtel:
>> Le 22/05/2015 22:50, Alexander Holler a écrit :
>
>>> First I think if NETLINK_LISTEN_ALL_NSID is enabled, a dump
>>> of the interfaces through RTM_GETLINK together with NLM_F_DUMP and
>>> NLM_F_REQUEST should return all interfaces of all reachable namespaces.
>> This option is only for 'listening', ie spontaneous notifications from the
>> kernel. It does nothing for request.
>
> The problem is that you need informations about the affected interfaces. E.g. if
> you receive an NEWADDR or NEWROUTE for some interface (indicated by the index of
> the interface) in a(nother) namespace, how do you get informations about that
> interface, if not by a dump which includes the interfaces of these namespaces
> too? Without knowledge about the interface, these messages are not very usable. ;)
Yes, this is the right things.

Usually, a daemon opens a socket to listen netlink event. Then, it opens
another netlink socket to dump the configuration (interfaces, addresses,
routes, etc.) and fill its internal structures. Starting from that point, for
most of configuration parameters, it doesn't need anymore to do dumps and thus
it can close the second socket. This allows your daemon to have only one socket
to monitor a set a netns.
Look at iproute for example, it starts by dumping all interfaces before
executing the specified command.

>
>> Not sure to follow you. veth0 sits in the current netns (let's say
>> init_net)
>> and veth1 in netns1.
>> So, when you dump veth0 in init_net, its link-netnsid is set to the id of
>> netns1 in init_net. And when you dump veth1 in netns1, it's link-netnsid
>> is set
>> to the id of init_net in netns1.
>
> I've misunderstood the meaning of IFLA_LINK_NETNSID. I thought it indicates the
> namespace an interface lives in, but it indicates the namespace it is linked too.
Yes.

>
> I've also thought that the NETNSID is a global unique identifier of a namespace,
> which seems to be wrong too. While I still not have read through all the
> sources, the other comments are suggesting that the NSID is just an ID which is
> unique only in one namespace, or in other words, every namespace has its own set
> of nsids. I'm not sure if I'm now right with that assumption, but that's what I
> now think after the responses to my mail. ;)
Right, nsid are local to a netns. This allows to migrate a container. With a
global id, that won't be possible. ifindex are local for the exact same purpose.

>
> So to conclude, I've now scheduled support for namespaces to a far later point.
> It doesn't seem to be as easy as I've thought after having read the introductory
> mail of your patch series. ;)
The main goal of the series was to improve scalability ;-)


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