On Fri, Nov 30, 2018 at 03:18:25PM -0800, Joe Stringer wrote: > On Fri, 30 Nov 2018 at 14:42, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > > > On Thu, Nov 29, 2018 at 04:29:33PM -0800, Joe Stringer wrote: > > > David Ahern and Nicolas Dichtel report that the handling of the netns id > > > 0 is incorrect for the BPF socket lookup helpers: rather than finding > > > the netns with id 0, it is resolving to the current netns. This renders > > > the netns_id 0 inaccessible. > > > > > > To fix this, adjust the API for the netns to treat all negative s32 > > > values as a lookup in the current netns, while any values with a > > > positive value in the signed 32-bit integer space would result in a > > > lookup for a socket in the netns corresponding to that id. As before, if > > > the netns with that ID does not exist, no socket will be found. > > > Furthermore, if any bits are set in the upper 32-bits, then no socket > > > will be found. > > > > > > Signed-off-by: Joe Stringer <j...@wand.net.nz> > > .. > > > +/* Current network namespace */ > > > +#define BPF_CURRENT_NETNS (-1L) > > > > I was about to apply it, but then noticed that the name doesn't match > > the rest of the names. > > Could you rename it to BPF_F_CURRENT_NETNS ? > > I skipped the F_ part since it's not really a flag, it's a value. I > can put it back though.
BPF_F_ prefix has smaller chance of conflicts. I wish we did that sooner. In retrospect BPF_ANY, BPF_EXIST were poorly picked names.
