Le 31/05/2017 à 20:34, Flavio Leitner a écrit :

On Wed, May 31, 2017 at 03:48:06PM +0200, Nicolas Dichtel wrote:

quoted

Le 31/05/2017 à 14:28, Flavio Leitner a écrit :

quoted

On Wed, May 31, 2017 at 10:38:21AM +0200, Nicolas Dichtel wrote:

quoted

Le 30/05/2017 à 23:33, Flavio Leitner a écrit :

quoted

Don't include netns id for notifications broadcasts when the
socket and the skb are in the same netns because it will be
an error which can't be distinguished from a peer netns failing
to allocate an id.

I don't understand the problem. peernet2id() doesn't allocate ids, it only do a
lookup. If you need an id for the current netns, you have to allocate one.

The issue is that if you query an interface on the same netns, the
error is returned, then we cannot tell if the iface is on the same
netns or if there was an error while allocating the ID and the
iface is on another netns.

If the returned id is NETNSA_NSID_NOT_ASSIGNED, then the netns is the same.

Some lines before your patch, we call peernet_has_id() when the netns differ,
thus we ensure that the id is available.

Right, but that's internal to the kernel.

Sure, but a good example exists in iproute2:
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/tree/ip/ipmonitor.c#n45

quoted

The principle was that netlink messages of other netns can be sent only if an id
is assigned.

OK, could you please update include/uapi/linux/net_namespace.h to reflect that?
It says NETNSA_NSID_NOT_ASSIGNED are attributes for RTM_NEWNSID or RTM_GETNSID
which makes sense, but NOT_ASSIGNED sounds little like SAME_NSID for other
message types.

I agree, it's confusing. I will send a patch.