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@xxxxxxxxx> 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@xxxxxxxxx>
>
--
- Justin
|