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.