Re: [PATCH net-next] netlink: include netnsid only when netns differs.

2017-06-01 Thread Nicolas Dichtel
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.


Re: [PATCH net-next] netlink: include netnsid only when netns differs.

2017-05-31 Thread Flavio Leitner
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.

> 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.

-- 
Flavio



Re: [PATCH net-next] netlink: include netnsid only when netns differs.

2017-05-31 Thread Nicolas Dichtel
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.

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

> 
>> This patch changes the metadata exported to the userland and will break 
>> existing
>> tools.
> 
> It should not break because it changes only for interfaces on
> the same netns where there is no ID and that value wasn't
> exported until recently.
> 
It was exported since the initial patch (59324cf35aba ("netlink: allow to listen
"all" netns"). Am I wrong?


Regards,
Nicolas


Re: [PATCH net-next] netlink: include netnsid only when netns differs.

2017-05-31 Thread Flavio Leitner
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.

> This patch changes the metadata exported to the userland and will break 
> existing
> tools.

It should not break because it changes only for interfaces on
the same netns where there is no ID and that value wasn't
exported until recently.

-- 
Flavio



Re: [PATCH net-next] netlink: include netnsid only when netns differs.

2017-05-31 Thread Nicolas Dichtel
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.

This patch changes the metadata exported to the userland and will break existing
tools.