kernel/linux.git/tools/lib, branch v6.12.80

libperf build: Always place libperf includes first

2026-03-04T12:20:50+00:00

[ Upstream commit 8c5b40678c63be6b85f1c2dc8c8b89d632faf988 ] When building tools/perf the CFLAGS can contain a directory for the installed headers. As the headers may be being installed while building libperf.a this can cause headers to be partially installed and found in the include path while building an object file for libperf.a. The installed header may reference other installed headers that are missing given the partial nature of the install and then the build fails with a missing header file. Avoid this by ensuring the libperf source headers are always first in the CFLAGS. Fixes: 3143504918105156 ("libperf: Make libperf.a part of the perf build") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

libperf: Don't remove -g when EXTRA_CFLAGS are used

2026-03-04T12:20:50+00:00

[ Upstream commit f5b07010c13c77541e8ade167d05bef3b8a63739 ] When using EXTRA_CFLAGS, for example "EXTRA_CFLAGS=-DREFCNT_CHECKING=1", this construct stops setting -g which you'd expect would not be affected by adding extra flags. Additionally, EXTRA_CFLAGS should be the last thing to be appended so that it can be used to undo any defaults. And no condition is required, just += appends to any existing CFLAGS and also appends or doesn't append EXTRA_CFLAGS if they are or aren't set. It's not clear why DEBUG=1 is required for -g in Perf when in libperf it's always on, but I don't think we need to change that behavior now because someone may be depending on it. Signed-off-by: James Clark Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250319114009.417865-1-james.clark@linaro.org Signed-off-by: Namhyung Kim Stable-dep-of: 8c5b40678c63 ("libperf build: Always place libperf includes first") Signed-off-by: Sasha Levin

libsubcmd: Fix null intersection case in exclude_cmds()

2026-03-04T12:20:49+00:00

[ Upstream commit b6ee9b6e206b288921c14c906eebf4b32fe0c0d8 ] When there is no exclusion occurring from the cmds list - for example - cmds contains ["read-vdso32"] and excludes contains ["archive"] - the main loop completes with ci == cj == 0. In the original code the loop processing the remaining elements in the list was conditional: if (ci != cj) { ...} So we end up in the assertion loop since ci < cmds->cnt and we incorrectly try to assert the list elements to be NULL and fail with the following error help.c:104: exclude_cmds: Assertion `cmds->names[ci] == NULL' failed. Fix this by moving the if (ci != cj) check inside of a broader loop. If ci != cj, left shift the list elements, as before, and then unconditionally advance the ci and cj indicies which also covers the ci == cj case. Fixes: 1fdf938168c4d26f ("perf tools: Fix use-after-free in help_unknown_cmd()") Reviewed-by: Guilherme Amadio Signed-off-by: Sri Jayaramappa Tested-by: Guilherme Amadio Tested-by: Ian Rogers Cc: Joshua Hunt Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20251202213632.2873731-1-sjayaram@akamai.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

bpftool: Fix truncated netlink dumps

2026-03-04T12:20:38+00:00

[ Upstream commit 3b39d73cc3379360a33eb583b17f21fe55e1288e ] Netlink requires that the recv buffer used during dumps is at least min(PAGE_SIZE, 8k) (see the man page). Otherwise the messages will get truncated. Make sure bpftool follows this requirement, avoid missing information on systems with large pages. Acked-by: Quentin Monnet Fixes: 7084566a236f ("tools/bpftool: Remove libbpf_internal.h usage in bpftool") Signed-off-by: Jakub Kicinski Link: https://lore.kernel.org/r/20260217194150.734701-1-kuba@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

libbpf: Fix OOB read in btf_dump_get_bitfield_value

2026-03-04T12:19:33+00:00

[ Upstream commit 5714ca8cba5ed736f3733663c446cbee63a10a64 ] When dumping bitfield data, btf_dump_get_bitfield_value() reads data based on the underlying type's size (t->size). However, it does not verify that the provided data buffer (data_sz) is large enough to contain these bytes. If btf_dump__dump_type_data() is called with a buffer smaller than the type's size, this leads to an out-of-bounds read. This was confirmed by AddressSanitizer in the linked issue. Fix this by ensuring we do not read past the provided data_sz limit. Fixes: a1d3cc3c5eca ("libbpf: Avoid use of __int128 in typed dump display") Reported-by: Harrison Green Suggested-by: Alan Maguire Signed-off-by: Varun R Mallya Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260106233527.163487-1-varunrmallya@gmail.com Closes: https://github.com/libbpf/libbpf/issues/928 Signed-off-by: Sasha Levin

libbpf: Fix -Wdiscarded-qualifiers under C23

2026-02-06T15:55:49+00:00

commit d70f79fef65810faf64dbae1f3a1b5623cdb2345 upstream. glibc ≥ 2.42 (GCC 15) defaults to -std=gnu23, which promotes -Wdiscarded-qualifiers to an error. In C23, strstr() and strchr() return "const char *". Change variable types to const char * where the pointers are never modified (res, sym_sfx, next_path). Suggested-by: Florian Weimer Suggested-by: Andrii Nakryiko Signed-off-by: Mikhail Gavrilov Link: https://lore.kernel.org/r/20251206092825.1471385-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Alexei Starovoitov [ shung-hsi.yu: needed to fix kernel build failure due to libbpf since glibc 2.43+ (which adds 'const' qualifier to strstr). 'sym_sfx' hunk dropped because commit f8a05692de06 ("libbpf: Work around kernel inconsistently stripping '.llvm.' suffix") is not present. ] Signed-off-by: Shung-Hsi Yu Signed-off-by: Greg Kroah-Hartman

libperf cpumap: Fix perf_cpu_map__max for an empty/NULL map

2026-01-08T09:14:12+00:00

[ Upstream commit a0a4173631bfcfd3520192c0a61cf911d6a52c3a ] Passing an empty map to perf_cpu_map__max triggered a SEGV. Explicitly test for the empty map. Reported-by: Ingo Molnar Closes: https://lore.kernel.org/linux-perf-users/aSwt7yzFjVJCEmVp@gmail.com/ Tested-by: Ingo Molnar Signed-off-by: Ian Rogers Tested-by: Thomas Richter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

libbpf: Fix parsing of multi-split BTF

2025-12-18T12:54:53+00:00

[ Upstream commit 4f596acc260e691a2e348f64230392f3472feea3 ] When creating multi-split BTF we correctly set the start string offset to be the size of the base string section plus the base BTF start string offset; the latter is needed for multi-split BTF since the offset is non-zero there. Unfortunately the BTF parsing case needed that logic and it was missed. Fixes: 4e29128a9ace ("libbpf/btf: Fix string handling to support multi-split BTF") Signed-off-by: Alan Maguire Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20251104203309.318429-2-alan.maguire@oracle.com Signed-off-by: Sasha Levin

tools: lib: thermal: use pkg-config to locate libnl3

2025-11-13T20:34:35+00:00

[ Upstream commit b31f7f725cd932e2c2b41f3e4b66273653953687 ] To make libthermal more cross compile friendly use pkg-config to locate libnl3. Only if that fails fall back to hardcoded /usr/include/libnl3. Signed-off-by: Sascha Hauer Acked-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

tools: lib: thermal: don't preserve owner in install

2025-11-13T20:34:34+00:00

[ Upstream commit 1375152bb02ab2a8435e87ea27034482dbc95f57 ] Instead of preserving mode, timestamp, and owner, for the object files during installation, just preserve the mode and timestamp. When installing as root, the installed files should be owned by root. When installing as user, --preserve=ownership doesn't work anyway. This makes --preserve=ownership rather pointless. Signed-off-by: Emil Dahl Juhl Signed-off-by: Sascha Hauer Acked-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin