On 11/20/18 2:05 AM, Nicolas Dichtel wrote:
> Le 20/11/2018 à 00:46, David Ahern a écrit :
> [snip]
>> That revelation shows another hole:
>> $ ip netns add foo
>> $ ip netns set foo 0x
> It also works with 0xf000 ...
>
>> $ ip netns list
>> foo (id: 0)
>>
>> Seems like alloc_netid() s
Le 20/11/2018 à 16:46, David Ahern a écrit :
> On 11/20/18 2:05 AM, Nicolas Dichtel wrote:
>> Le 20/11/2018 à 00:46, David Ahern a écrit :
[snip]
>>> Seems like alloc_netid() should error out if reqid < -1 (-1 being the
>>> NETNSA_NSID_NOT_ASSIGNED flag) as opposed to blindly ignoring it.
>> alloc_
On 11/20/18 2:05 AM, Nicolas Dichtel wrote:
> Le 20/11/2018 à 00:46, David Ahern a écrit :
> [snip]
>> That revelation shows another hole:
>> $ ip netns add foo
>> $ ip netns set foo 0x
> It also works with 0xf000 ...
yes, I realized last night I sent a bad example. I meant any negativ
Le 20/11/2018 à 00:46, David Ahern a écrit :
[snip]
> That revelation shows another hole:
> $ ip netns add foo
> $ ip netns set foo 0x
It also works with 0xf000 ...
> $ ip netns list
> foo (id: 0)
>
> Seems like alloc_netid() should error out if reqid < -1 (-1 being the
> NETNSA_NSID_
On 11/19/18 2:59 PM, Joe Stringer wrote:
> @@ -2221,12 +,13 @@ union bpf_attr {
> * **sizeof**\ (*tuple*\ **->ipv6**)
> * Look for an IPv6 socket.
> *
> - * If the *netns* is zero, then the socket lookup table in the
> - * netns associa
On Mon, 19 Nov 2018 at 12:54, Joe Stringer wrote:
>
> On Mon, 19 Nov 2018 at 12:29, Nicolas Dichtel
> wrote:
> >
> > Le 19/11/2018 à 20:54, David Ahern a écrit :
> > > On 11/19/18 12:47 PM, Joe Stringer wrote:
> > >> On Mon, 19 Nov 2018 at 10:39, David Ahern wrote:
> > >>>
> > >>> On 11/19/18 1
On Mon, 19 Nov 2018 at 12:29, Nicolas Dichtel wrote:
>
> Le 19/11/2018 à 20:54, David Ahern a écrit :
> > On 11/19/18 12:47 PM, Joe Stringer wrote:
> >> On Mon, 19 Nov 2018 at 10:39, David Ahern wrote:
> >>>
> >>> On 11/19/18 11:36 AM, Joe Stringer wrote:
> Hi David, thanks for pointing this
Le 19/11/2018 à 20:54, David Ahern a écrit :
> On 11/19/18 12:47 PM, Joe Stringer wrote:
>> On Mon, 19 Nov 2018 at 10:39, David Ahern 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
On 11/19/18 12:47 PM, Joe Stringer wrote:
> On Mon, 19 Nov 2018 at 10:39, David Ahern 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
On Mon, 19 Nov 2018 at 10:39, David Ahern 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
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
>
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 thi
Hi Joe:
The netns_id to the bpf_sk_lookup_{tcp,udp} functions in
net/core/filter.c is a u64, yet the APIs in include/uapi/linux/bpf.h
shows a u32. Is that intentional or an oversight through the iterations?
David
13 matches
Mail list logo
