On 11/19/18 12:47 PM, Joe Stringer wrote:
> On Mon, 19 Nov 2018 at 10:39, David Ahern <dsah...@gmail.com> wrote:
>>
>> On 11/19/18 11:36 AM, Joe Stringer wrote:
>>> Hi David, thanks for pointing this out.
>>>
>>> This is more of an oversight through iterations, the runtime lookup
>>> will fail to find a socket if the netns value is greater than the
>>> range of a uint32 so I think it would actually make more sense to drop
>>> the parameter size to u32 rather than u64 so that this would be
>>> validated at load time rather than silently returning NULL because of
>>> a bad parameter.
>>
>> ok. I was wondering if it was a u64 to handle nsid of 0 which as I
>> understand it is a legal nsid. If you drop to u32, how do you know when
>> nsid has been set?
> 
> I was operating under the assumption that 0 represents the root netns
> id, and cannot be assigned to another non-root netns.
> 
> Looking at __peernet2id_alloc(), it seems to me like it attempts to
> find a netns and if it cannot find one, returns 0, which then leads to
> a scroll over the idr starting from 0 to INT_MAX to find a legitimate
> id for the netns, so I think this is a fair assumption?
> 

Maybe Nicolas can give a definitive answer; as I recall he added the
NSID option. I have not had time to walk the code. But I do recall
seeing an id of 0. e.g, on my dev box:
$ ip netns
vms (id: 0)

And include/uapi/linux/net_namespace.h shows -1 as not assigned.

Reply via email to