diff options
author | Andrii Nakryiko <andrii@kernel.org> | 2025-07-18 03:10:09 +0300 |
---|---|---|
committer | Alexei Starovoitov <ast@kernel.org> | 2025-07-18 05:17:46 +0300 |
commit | 0238c45fbbf8228f52aa4642f0cdc21c570d1dfe (patch) | |
tree | 6f3240ed89e9da0c78771706010e066f787a3e0a /scripts/gdb/linux/interrupts.py | |
parent | 2e2713ae1a05eea7dda2f3b6988827196e33b25a (diff) | |
download | linux-0238c45fbbf8228f52aa4642f0cdc21c570d1dfe.tar.xz |
libbpf: Fix handling of BPF arena relocations
Initial __arena global variable support implementation in libbpf
contains a bug: it remembers struct bpf_map pointer for arena, which is
used later on to process relocations. Recording this pointer is
problematic because map pointers are not stable during ELF relocation
collection phase, as an array of struct bpf_map's can be reallocated,
invalidating all the pointers. Libbpf is dealing with similar issues by
using a stable internal map index, though for BPF arena map specifically
this approach wasn't used due to an oversight.
The resulting behavior is non-deterministic issue which depends on exact
layout of ELF object file, number of actual maps, etc. We didn't hit
this until very recently, when this bug started triggering crash in BPF
CI when validating one of sched-ext BPF programs.
The fix is rather straightforward: we just follow an established pattern
of remembering map index (just like obj->kconfig_map_idx, for example)
instead of `struct bpf_map *`, and resolving index to a pointer at the
point where map information is necessary.
While at it also add debug-level message for arena-related relocation
resolution information, which we already have for all other kinds of
maps.
Fixes: 2e7ba4f8fd1f ("libbpf: Recognize __arena global variables.")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Tested-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20250718001009.610955-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'scripts/gdb/linux/interrupts.py')
0 files changed, 0 insertions, 0 deletions