user/sven/linux.git/tools/lib/bpf, branch v6.17.10

libbpf: Fix USDT SIB argument handling causing unrecognized register error

2025-11-13T20:36:47Z

[ Upstream commit 758acb9ccfdbf854b55abaceaf1f3f229cde3d19 ] On x86-64, USDT arguments can be specified using Scale-Index-Base (SIB) addressing, e.g. "1@-96(%rbp,%rax,8)". The current USDT implementation in libbpf cannot parse this format, causing `bpf_program__attach_usdt()` to fail with -ENOENT (unrecognized register). This patch fixes this by implementing the necessary changes: - add correct handling for SIB-addressed arguments in `bpf_usdt_arg`. - add adaptive support to `__bpf_usdt_arg_type` and `__bpf_usdt_arg_spec` to represent SIB addressing parameters. Signed-off-by: Jiawei Zhao Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250827053128.1301287-2-phoenix500526@163.com Signed-off-by: Sasha Levin

libbpf: Fix powerpc's stack register definition in bpf_tracing.h

2025-11-13T20:36:40Z

[ Upstream commit 7221b9caf84b3294688228a19273d74ea19a2ee4 ] retsnoop's build on powerpc (ppc64le) architecture ([0]) failed due to wrong definition of PT_REGS_SP() macro. Looking at powerpc's implementation of stack unwinding in perf_callchain_user_64() clearly shows that stack pointer register is gpr[1]. Fix libbpf's definition of __PT_SP_REG for powerpc to fix all this. [0] https://kojipkgs.fedoraproject.org/work/tasks/1544/137921544/build.log Fixes: 138d6153a139 ("samples/bpf: Enable powerpc support") Signed-off-by: Andrii Nakryiko Reviewed-by: Naveen N Rao (AMD) Link: https://lore.kernel.org/r/20251020203643.989467-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

libbpf: Fix error when st-prefix_ops and ops from differ btf

2025-10-15T10:03:38Z

[ Upstream commit 0cc114dc358cf8da2ca23a366e761e89a46ca277 ] When a module registers a struct_ops, the struct_ops type and its corresponding map_value type ("bpf_struct_ops_") may reside in different btf objects, here are four possible case: +--------+---------------+-------------+---------------------------------+ | |bpf_struct_ops_| xxx_ops | | +--------+---------------+-------------+---------------------------------+ | case 0 | btf_vmlinux | btf_vmlinux | be used and reg only in vmlinux | +--------+---------------+-------------+---------------------------------+ | case 1 | btf_vmlinux | mod_btf | INVALID | +--------+---------------+-------------+---------------------------------+ | case 2 | mod_btf | btf_vmlinux | reg in mod but be used both in | | | | | vmlinux and mod. | +--------+---------------+-------------+---------------------------------+ | case 3 | mod_btf | mod_btf | be used and reg only in mod | +--------+---------------+-------------+---------------------------------+ Currently we figure out the mod_btf by searching with the struct_ops type, which makes it impossible to figure out the mod_btf when the struct_ops type is in btf_vmlinux while it's corresponding map_value type is in mod_btf (case 2). The fix is to use the corresponding map_value type ("bpf_struct_ops_") as the lookup anchor instead of the struct_ops type to figure out the `btf` and `mod_btf` via find_ksym_btf_id(), and then we can locate the kern_type_id via btf__find_by_name_kind() with the `btf` we just obtained from find_ksym_btf_id(). With this change the lookup obtains the correct btf and mod_btf for case 2, preserves correct behavior for other valid cases, and still fails as expected for the invalid scenario (case 1). Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support") Signed-off-by: D. Wythe Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20250926071751.108293-1-alibuda@linux.alibaba.com Signed-off-by: Sasha Levin

libbpf: Export bpf_object__prepare symbol

2025-10-15T10:03:20Z

[ Upstream commit 2693227c1150d58bf82ef45a394a554373be5286 ] Add missing LIBBPF_API macro for bpf_object__prepare function to enable its export. libbpf.map had bpf_object__prepare already listed. Fixes: 1315c28ed809 ("libbpf: Split bpf object load into prepare/load") Signed-off-by: Mykyta Yatsenko Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20250819215119.37795-1-mykyta.yatsenko5@gmail.com Signed-off-by: Sasha Levin

libbpf: Fix reuse of DEVMAP

2025-10-15T10:03:19Z

[ Upstream commit 6c6b4146deb12d20f42490d5013f2043df942161 ] Previously, re-using pinned DEVMAP maps would always fail, because get_map_info on a DEVMAP always returns flags with BPF_F_RDONLY_PROG set, but BPF_F_RDONLY_PROG being set on a map during creation is invalid. Thus, ignore the BPF_F_RDONLY_PROG flag in the flags returned from get_map_info when checking for compatibility with an existing DEVMAP. The same problem is handled in a third-party ebpf library: - https://github.com/cilium/ebpf/issues/925 - https://github.com/cilium/ebpf/pull/930 Fixes: 0cdbb4b09a06 ("devmap: Allow map lookups from eBPF") Signed-off-by: Yureka Lilian Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250814180113.1245565-3-yuka@yuka.dev Signed-off-by: Sasha Levin

libbpf: Add the ability to suppress perf event enablement

2025-08-07T16:01:41Z

Automatically enabling a perf event after attaching a BPF prog to it is not always desirable. Add a new "dont_enable" field to struct bpf_perf_event_opts. While introducing "enable" instead would be nicer in that it would avoid a double negation in the implementation, it would make DECLARE_LIBBPF_OPTS() less efficient. Acked-by: Eduard Zingerman Suggested-by: Jiri Olsa Tested-by: Thomas Richter Co-developed-by: Thomas Richter Signed-off-by: Thomas Richter Signed-off-by: Ilya Leoshkevich Link: https://lore.kernel.org/r/20250806162417.19666-2-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov

libbpf: Avoid possible use of uninitialized mod_len

2025-07-31T18:39:46Z

Though mod_len is only read when mod_name != NULL and both are initialized together, gcc15 produces a warning with -Werror=maybe-uninitialized: libbpf.c: In function 'find_kernel_btf_id.constprop': libbpf.c:10100:33: error: 'mod_len' may be used uninitialized [-Werror=maybe-uninitialized] 10100 | if (mod_name && strncmp(mod->name, mod_name, mod_len) != 0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libbpf.c:10070:21: note: 'mod_len' was declared here 10070 | int ret, i, mod_len; | ^~~~~~~ Silence the false positive. Signed-off-by: Achill Gilgenast Acked-by: Yonghong Song Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250729094611.2065713-1-fossdd@pwned.life Signed-off-by: Alexei Starovoitov

libbpf: Verify that arena map exists when adding arena relocations

2025-07-19T00:12:50Z

Fuzzer reported a memory access error in bpf_program__record_reloc() that happens when: - ".addr_space.1" section exists - there is a relocation referencing this section - there are no arena maps defined in BTF. Sanity checks for maps existence are already present in bpf_program__record_reloc(), hence this commit adds another one. [1] https://github.com/libbpf/libbpf/actions/runs/16375110681/job/46272998064 Signed-off-by: Eduard Zingerman Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250718222059.281526-1-eddyz87@gmail.com

Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after rc6

2025-07-18T19:15:59Z

Cross-merge BPF and other fixes after downstream PR. No conflicts. Signed-off-by: Alexei Starovoitov

libbpf: Fix warning in calloc() usage

2025-07-18T15:29:50Z

When compiling libbpf with some compilers, this warning is triggered: libbpf.c: In function ‘bpf_object__gen_loader’: libbpf.c:9209:28: error: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] 9209 | gen = calloc(sizeof(*gen), 1); | ^ libbpf.c:9209:28: note: earlier argument should specify number of elements, later size of each element Fix this by inverting the calloc() arguments. Signed-off-by: Matteo Croce Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20250717200337.49168-1-technoboy85@gmail.com