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

Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

2026-07-10T12:27:31+00:00

libbpf: Drop in-loader metadata check for load-time verification

2026-07-08T18:04:46+00:00

The signed gen_loader used to police its own metadata map from within BPF: emit_signature_match() read the kernel-cached map->sha[] back through hardcoded struct bpf_map offsets and compared it against a hash that compute_sha_update_offsets() baked into the signed instructions, after a BPF_OBJ_GET_INFO_BY_FD round-trip to populate map->sha[]. The kernel now verifies the metadata at BPF_PROG_LOAD time by folding the frozen contents of the loader's exclusive fd_array maps into the signature, so the loader no longer checks anything itself. Generated loaders thus carry no verification logic of their own anymore: Nothing in the signing chain depends on emitted loader bytecode doing the right thing. On the loading side, skel_internal.h now sets fd_array_cnt for a signed load so the kernel scans fd_array for the exclusive metadata map - still frozen, as the kernel requires - and the BPF_OBJ_GET_INFO_BY_FD round-trip to populate map->sha[] is gone. The struct bpf_map layout BUILD_BUG_ON()s on the kernel side are removed as well: they only pinned the ABI for the in-BPF read of map->sha[] that is no longer needed. Same for the map->excl member. Note: gen_hash is retained; it still marks a loader as signed so an untrusted host cannot re-dimension maps or override initial values now covered by the signature. Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260708075343.358712-4-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi

libbpf: Detect uprobe syscall with new error

2026-07-04T08:56:30+00:00

In the previous optimized uprobe fix we changed the syscall error used for its detection from ENXIO to EPROTO. Changing related probe_uprobe_syscall detection check. Fixes: 05738da0efa1 ("libbpf: Add uprobe syscall feature detection") Fixes: 554ba38456da ("uprobes/x86: Move optimized uprobe from nop5 to nop10") Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Acked-by: Andrii Nakryiko Link: https://patch.msgid.link/20260703114917.238144-8-jolsa@kernel.org

libbpf: Change has_nop_combo to work on top of nop10

2026-07-04T08:54:59+00:00

We now expect nop combo with 10 bytes nop instead of 5 bytes nop, fixing has_nop_combo to reflect that. Fixes: 41a5c7df4466 ("libbpf: Add support to detect nop,nop5 instructions combo for usdt probe") Fixes: 554ba38456da ("uprobes/x86: Move optimized uprobe from nop5 to nop10") Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Jakub Sitnicki Acked-by: Andrii Nakryiko Link: https://patch.msgid.link/20260703114917.238144-7-jolsa@kernel.org

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: Initialize CFLAGS before including Makefile.include

2026-06-15T00:32:53+00:00

tools/scripts/Makefile.include may expand EXTRA_CFLAGS in a future change. This could alter the initialization of CFLAGS, as the default options "-g -O2" would never be set once EXTRA_CFLAGS is expanded. Prepare for this by moving the CFLAGS initialization before including tools/scripts/Makefile.include, so it is not affected by the extended EXTRA_CFLAGS. Append EXTRA_CFLAGS to CFLAGS only after including Makefile.include and place it last so that the extra flags propagate properly and can override the default options. tools/scripts/Makefile.include already appends $(CLANG_CROSS_FLAGS) to CFLAGS, the Makefile appends $(CLANG_CROSS_FLAGS) again, remove the redundant append. Signed-off-by: Leo Yan Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260602-tools_build_fix_zero_init_bpf_only-v2-4-c76e5250ea1c@arm.com Signed-off-by: Alexei Starovoitov

libbpf: Add path_fd to struct bpf_link_create_opts

2026-06-15T00:24:25+00:00

Adding the path_fd field to struct bpf_link_create_opts and passing it through kernel attr interface. Assisted-by: Codex:GPT-5.4 Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260611114230.950379-5-jolsa@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