mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
synced 2024-12-29 17:22:07 +00:00
edbca120a8
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: |
||
---|---|---|
.. | ||
auxdisplay | ||
binderfs | ||
bpf | ||
configfs | ||
connector | ||
ftrace | ||
hidraw | ||
hw_breakpoint | ||
kdb | ||
kfifo | ||
kobject | ||
kprobes | ||
livepatch | ||
mei | ||
mic/mpssd | ||
pidfd | ||
pktgen | ||
qmi | ||
rpmsg | ||
seccomp | ||
timers | ||
trace_events | ||
trace_printk | ||
uhid | ||
v4l | ||
vfio-mdev | ||
vfs | ||
watchdog | ||
Kconfig | ||
Makefile |