diff options
author | Jesper Dangaard Brouer <brouer@redhat.com> | 2019-12-02 13:37:31 +0100 |
---|---|---|
committer | Alexei Starovoitov <ast@kernel.org> | 2019-12-04 17:54:15 -0800 |
commit | edbca120a8cdfa5a5793707e33497aa5185875ca (patch) | |
tree | 0503e0d8d7acdf7ccac3a62e123e232a956c5b17 /crypto/aegis128-neon.c | |
parent | 099ffd7eddfe03b9b5b43e1f4ffece99121dd7ba (diff) | |
download | linux-edbca120a8cdfa5a5793707e33497aa5185875ca.tar.gz linux-edbca120a8cdfa5a5793707e33497aa5185875ca.tar.bz2 linux-edbca120a8cdfa5a5793707e33497aa5185875ca.zip |
samples/bpf: Fix broken xdp_rxq_info due to map order assumptions
In the days of using bpf_load.c the order in which the 'maps' sections
were defines in BPF side (*_kern.c) file, were used by userspace side
to identify the map via using the map order as an index. In effect the
order-index is created based on the order the maps sections are stored
in the ELF-object file, by the LLVM compiler.
This have also carried over in libbpf via API bpf_map__next(NULL, obj)
to extract maps in the order libbpf parsed the ELF-object file.
When BTF based maps were introduced a new section type ".maps" were
created. I found that the LLVM compiler doesn't create the ".maps"
sections in the order they are defined in the C-file. The order in the
ELF file is based on the order the map pointer is referenced in the code.
This combination of changes lead to xdp_rxq_info mixing up the map
file-descriptors in userspace, resulting in very broken behaviour, but
without warning the user.
This patch fix issue by instead using bpf_object__find_map_by_name()
to find maps via their names. (Note, this is the ELF name, which can
be longer than the name the kernel retains).
Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf")
Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/157529025128.29832.5953245340679936909.stgit@firesoul
Diffstat (limited to 'crypto/aegis128-neon.c')
0 files changed, 0 insertions, 0 deletions