Le 31/05/2017 à 20:34, Flavio Leitner a écrit : > On Wed, May 31, 2017 at 03:48:06PM +0200, Nicolas Dichtel wrote: >> Le 31/05/2017 à 14:28, Flavio Leitner a écrit : >>> On Wed, May 31, 2017 at 10:38:21AM +0200, Nicolas Dichtel wrote: >>>> Le 30/05/2017 à 23:33, Flavio Leitner a écrit : >>>>> 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
> >> 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.
