linux-next.git/tools/lib/bpf/libbpf.c, branch master

libbpf: Fix for the potential undefined behavior due to shifting

2026-08-28T17:28:04+00:00

When compiling libbpf with sanitation, ubsan will report the following: ``` left shift of 1 by 31 places cannot be represented in type 'int' ``` This may lead to undefined behavior according to the compiler implementation, let's fix it by casting to unsigned counterpart before shifting. Signed-off-by: Tan Wei Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260828003448.1684064-1-tw19881113@gmail.com

libbpf: Avoid unnecessary mmap resize for percpu data maps

2026-08-14T20:33:35+00:00

Use array_map_mmap_sz() for PERCPU_ARRAY like ARRAY in bpf_map_mmap_sz(). This lets bpf_map__set_value_size() skip mmap(), memcpy(), and munmap() when the old and new value sizes occupy the same number of pages. Fix some typos btw: * mmapble -> mmapable * satisified -> satisfied * relocatin -> relocation * atach_btf_obj_fd -> attach_btf_obj_fd * len_secnd -> len_second * precendence -> precedence Signed-off-by: Leon Hwang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260814173206.93082-3-leon.hwang@linux.dev

libbpf: Add support for global percpu data

2026-08-13T17:27:40+00:00

Add support for global percpu data in libbpf by adding a new ".percpu" section, similar to ".data". It enables efficient handling of percpu global variables in bpf programs. When generating loader for lightweight skeleton, update the percpu_array map used for global percpu data using BPF_F_ALL_CPUS, in order to update values across all CPUs using one value slot. Unlike global data, the mmaped data for global percpu data will be marked as read-only after populating the percpu_array map. Thereafter, users can read those initialized percpu data after loading prog. If they want to update the percpu data after loading prog, they have to update the percpu_array map using key=0 instead. Signed-off-by: Leon Hwang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260813152324.97937-6-leon.hwang@linux.dev

libbpf: Search /lib64 and /lib in resolve_full_path()

2026-07-21T17:27:13+00:00

attach_probe/uprobe-lib and uprobe_autoattach selftests fail with "failed to resolve full path for libc.so.6" on older non-usrmerged distros, where libc.so.6 lives under a top-level /lib64 or /lib rather than /usr/lib64 or /usr/lib. Add /lib64:/lib to the search paths, alongside the existing /usr/lib64:/usr/lib and Debian multiarch entries. Fixes: 1ce3a60e3c28 ("libbpf: auto-resolve programs/libraries when necessary for uprobes") Signed-off-by: Ricardo B. Marlière Acked-by: Ihor Solodrai Link: https://lore.kernel.org/bpf/20260720-selftests-bpf_fixes-v2-3-b450eda93dfe@suse.com Signed-off-by: Kumar Kartikeya Dwivedi

libbpf: Skip bpf_object__probe_loading() when BPF token is in use

2026-07-01T20:43:47+00:00

bpf_object__probe_loading() tries to load trivial SOCKET_FILTER and TRACEPOINT programs to verify the BPF environment works. When a BPF token is in use with restricted program type permissions, these probe loads may fail because the token does not allow the specific program types, even though BPF loading is perfectly functional. Fix by skipping the probe when a token FD is present: BPF token creation itself proves the kernel has a working BPF subsystem. Real BPF issues will be caught during actual program and map loading. Signed-off-by: Yuan Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260610145059.113412-2-chenyuan_fl@163.com

libbpf: fix -Wformat warnings from format/argument type mismatches

2026-06-26T00:56:22+00:00

Building libbpf with -Wall (as happens via bpftool's bootstrap build) surfaces ~120 -Wformat warnings where pr_warn/pr_debug format specifiers don't match their argument types: %d for __u32/Elf64_Word, %u for signed ints, %zd for size_t, %ld for unsigned long, and %x/%lx/%llx applied to signed values. Match each specifier to its argument's type where a correctly-signed specifier exists (%d<->%u, %ld->%lu, %zd->%zu). For hex conversions, which have no signed form, cast the argument instead (%x->(unsigned), %lx->(unsigned long), %llx->(unsigned long long)). No functional change. Note, the fdinfo map_flags sscanf used %i into a __u32 *, which warns. The kernel prints map_flags as hex ("map_flags:\t%#x\n" in bpf_map_show_fdinfo(), unchanged since the field was added to fdinfo), so switch the conversion to %x: it parses the 0x-prefixed value and expects unsigned int *, matching the destination, so the warning is gone with no cast. Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20260624204946.2901178-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov

libbpf: Add support to create tracing multi link

2026-06-07T17:03:02+00:00

Adding bpf_program__attach_tracing_multi function for attaching tracing program to multiple functions. struct bpf_link * bpf_program__attach_tracing_multi(const struct bpf_program *prog, const char *pattern, const struct bpf_tracing_multi_opts *opts); User can specify functions to attach with 'pattern' argument that allows wildcards (*?' supported) or provide BTF ids of functions in array directly via opts argument. These options are mutually exclusive. When using BTF ids, user can also provide cookie value for each provided id/function, that can be retrieved later in bpf program with bpf_get_attach_cookie helper. Each cookie value is paired with provided BTF id with the same array index. Adding support to auto attach programs with following sections: fsession.multi/ fsession.multi.s/ fentry.multi/ fexit.multi/ fentry.multi.s/ fexit.multi.s/ The provided is used as 'pattern' argument in bpf_program__attach_kprobe_multi_opts function. The allows to specify optional kernel module name with following syntax: : In order to attach tracing_multi link to a module functions: - program must be loaded with 'module' btf fd (in attr::attach_btf_obj_fd) - bpf_program__attach_tracing_multi must either have pattern with module spec or BTF ids from the module Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260606123955.345967-21-jolsa@kernel.org Signed-off-by: Alexei Starovoitov

libbpf: Add btf_type_is_traceable_func function

2026-06-07T17:03:02+00:00

Adding btf_type_is_traceable_func function to perform same checks as the kernel's btf_distill_func_proto function to prevent attachment on some of the functions. Exporting the function via libbpf_internal.h because it will be used by benchmark test in following changes. Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260606123955.345967-20-jolsa@kernel.org Signed-off-by: Alexei Starovoitov

libbpf: Add bpf_object_cleanup_btf function

2026-06-07T17:03:02+00:00

Adding bpf_object_cleanup_btf function to cleanup btf objects. It will be used in following changes. Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260606123955.345967-18-jolsa@kernel.org Signed-off-by: Alexei Starovoitov

bpf: Add support for tracing_multi link session

2026-06-07T17:03:01+00:00

Adding support to use session attachment with tracing_multi link. Adding new BPF_TRACE_FSESSION_MULTI program attach type, that follows the BPF_TRACE_FSESSION behaviour but on the tracing_multi link. Such program is called on entry and exit of the attached function and allows to pass cookie value from entry to exit execution. Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260606123955.345967-16-jolsa@kernel.org Signed-off-by: Alexei Starovoitov