mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-17 17:53:56 +08: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 | ||