On Fri, 30 Nov 2018 at 17:36, Alexei Starovoitov
wrote:
>
> On Fri, Nov 30, 2018 at 03:32:20PM -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,
On Fri, Nov 30, 2018 at 03:32:20PM -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
On Fri, Nov 30, 2018 at 02:36:57PM -1000, Joey Pabalinas wrote:
> On Fri, Nov 30, 2018 at 03:32:20PM -0800, Joe Stringer wrote:
> > + * the netns associated with the *ctx*. *netns* values beyond the
> > + * range of 32-bit integers are reserved for future use.
>
> Would adding a wo
On Fri, Nov 30, 2018 at 03:32:20PM -0800, Joe Stringer wrote:
> + * the netns associated with the *ctx*. *netns* values beyond the
> + * range of 32-bit integers are reserved for future use.
Would adding a word or two before "*netns*" here be helpful to placate
the english peda
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
