All of lore.kernel.org
 help / color / mirror / Atom feed
* Pinning map and libbpf
@ 2018-11-15 18:20 Eric Leblond
  2018-11-16 16:43 ` Justin Azoff
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Leblond @ 2018-11-15 18:20 UTC (permalink / raw)
  To: Xdp

Hi,

I've just added an libbpf bpf_pin_obj call to a working setup and this
did cause bpf_map_lookup_elem() call to fail and return a value even if
the set is empty.

The maps structure is the following:

struct bpf_map_def SEC("maps") ipv4_drop = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(__u32),
    .value_size = sizeof(__u32),
    .max_entries = 32768,
};

Is there something I should change ?

I'm using 4.18. 

BR,
-- 
Eric Leblond <eric@regit.org>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Pinning map and libbpf
  2018-11-15 18:20 Pinning map and libbpf Eric Leblond
@ 2018-11-16 16:43 ` Justin Azoff
  2018-11-16 18:50   ` Eric Leblond
  0 siblings, 1 reply; 3+ messages in thread
From: Justin Azoff @ 2018-11-16 16:43 UTC (permalink / raw)
  To: eric; +Cc: xdp-newbies

This sounds similar to an issue I ran into when I was getting pinning
working for libflowbypass.  At one point I was pinning the map but not
loading it properly again on startup.  This caused a 2nd map with the
same name to be created.  This meant anything using the pinned map on
the bpf filesystem saw one set of values, but the app was running with
it's own private non-pinned map.

If you do a 'bpftool map list' when the app is stopped, you should see
your pinned map. If you start the app back up and 'bpftool map list'
now lists 2 maps, that would be your problem as well.  If nothing
else, 'bpftool map list' and 'bpftool map dump' may also help debug
this, since they should be able to confirm that the map is empty too.

On Thu, Nov 15, 2018 at 12:57 PM Eric Leblond <eric@regit.org> wrote:
>
> Hi,
>
> I've just added an libbpf bpf_pin_obj call to a working setup and this
> did cause bpf_map_lookup_elem() call to fail and return a value even if
> the set is empty.
>
> The maps structure is the following:
>
> struct bpf_map_def SEC("maps") ipv4_drop = {
>     .type = BPF_MAP_TYPE_HASH,
>     .key_size = sizeof(__u32),
>     .value_size = sizeof(__u32),
>     .max_entries = 32768,
> };
>
> Is there something I should change ?
>
> I'm using 4.18.
>
> BR,
> --
> Eric Leblond <eric@regit.org>
>


-- 
- Justin

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Pinning map and libbpf
  2018-11-16 16:43 ` Justin Azoff
@ 2018-11-16 18:50   ` Eric Leblond
  0 siblings, 0 replies; 3+ messages in thread
From: Eric Leblond @ 2018-11-16 18:50 UTC (permalink / raw)
  To: Justin Azoff; +Cc: xdp-newbies

Hello,

On Fri, 2018-11-16 at 10:43 -0600, Justin Azoff wrote:
> This sounds similar to an issue I ran into when I was getting pinning
> working for libflowbypass.  At one point I was pinning the map but
> not
> loading it properly again on startup.  This caused a 2nd map with the
> same name to be created.  This meant anything using the pinned map on
> the bpf filesystem saw one set of values, but the app was running
> with
> it's own private non-pinned map.
> 
> If you do a 'bpftool map list' when the app is stopped, you should
> see
> your pinned map. If you start the app back up and 'bpftool map list'
> now lists 2 maps, that would be your problem as well.  If nothing
> else, 'bpftool map list' and 'bpftool map dump' may also help debug
> this, since they should be able to confirm that the map is empty too.

This is not that. I just did the following test:
 * reboot
 * start on 4.18 (4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-11-02)
   x86_64 GNU/Linux)
 * mount bpf fs
 * start suricata that create and pin the ipv4_drop map
 * do a ssh connection
 * check log generated by sniffing the traffic 

Result:
 * no SSH connection logged by Suricata
 * no packet seen by suricata (received by AF_PACKET) 

If I do the same tests with 4.17 kernel, then I've got a SSH logs and
Suricata sees packets.

On 4.18, I've got:
# sudo bpftool map dump pinned /sys/fs/bpf/ipv4_drop 
Found 0 elements

I've just seen now that even if I don't pin the map then I've got an
all block filter on 4.18.

Adding a 'return -1' at the start of the eBPF code is switching the
eBPF to pass so it seems it is the bpf map lookup that is causing the
error.

I'm going continue to investigate to see if I find something 

BR,


> On Thu, Nov 15, 2018 at 12:57 PM Eric Leblond <eric@regit.org> wrote:
> > Hi,
> > 
> > I've just added an libbpf bpf_pin_obj call to a working setup and
> > this
> > did cause bpf_map_lookup_elem() call to fail and return a value
> > even if
> > the set is empty.
> > 
> > The maps structure is the following:
> > 
> > struct bpf_map_def SEC("maps") ipv4_drop = {
> >     .type = BPF_MAP_TYPE_HASH,
> >     .key_size = sizeof(__u32),
> >     .value_size = sizeof(__u32),
> >     .max_entries = 32768,
> > };
> > 
> > Is there something I should change ?
> > 
> > I'm using 4.18.
> > 
> > BR,
> > --
> > Eric Leblond <eric@regit.org>
> > 
> 
> 
-- 
Eric Leblond <eric@regit.org>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-11-17  5:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-15 18:20 Pinning map and libbpf Eric Leblond
2018-11-16 16:43 ` Justin Azoff
2018-11-16 18:50   ` Eric Leblond

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.