kernel/git/stable/linux-stable.git/tools/lib/api, branch master

tools/build: selftests: Remove some duplicate toolchain definitions

2026-07-26T05:25:00+00:00

Try to remove some, but not all duplicate toolchain definitions. In these instances, their makefiles already include tools/scripts/Makefile.include which defines these in a consistent way. STRIP is the only one that was set with an '=', but I don't think it was significant so that difference can be dropped. Signed-off-by: James Clark Reviewed-by: Ian Rogers Acked-by: Ihor Solodrai Acked-by: Kumar Kartikeya Dwivedi Signed-off-by: Namhyung Kim

tools/lib/api: Fix potential double-free from fdarray__grow()

2026-07-16T16:56:47+00:00

If the realloc for fda->entries succeeds but the realloc for fda->priv fails, the error path frees the newly allocated entries. However, fda->entries is neither updated to point to the new entries block nor cleared to NULL. If realloc moved the allocation to a new block, the old fda->entries pointer is now freed memory. When fdarray__exit() is later called to clean up, it executes free(fda->entries), which would trigger a double-free on that old pointer. Reported-by: Sashiko Review Closes: https://lore.kernel.org/linux-perf-users/20260710200150.11FE71F00A3A@smtp.kernel.org Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim

perf record: Fix teardown hang on system-wide multi-threaded sessions

2026-07-10T22:30:05+00:00

Under system-wide (-a) parallel streaming mode (--threads=cpu), background recording threads can be inundated by a continuous firehose of hardware samples generated by the OS. In this state, a background thread's local hit count remains unequal to its sample count, causing it to bypass the blocking fdarray__poll() call entirely on each iteration of its recording loop. Because the termination check relies on the POLLHUP event status populated specifically by fdarray__poll(), bypassing it prevents the background thread from ever recognizing that its control pipe was closed by the main thread. This traps the background thread in an infinite recording loop, hanging the main thread indefinitely as it awaits a termination acknowledgment that never arrives. Ensure teardown completion by adding explicit evlist__disable() calls in the main thread's cleanup paths at out_child: and out_child_no_flush:. Additionally, patch fdarray__filter() to respect the fdarray_flag__nonfilterable flag, preventing it from incorrectly setting the background thread's control pipe file descriptor to -1 and clearing its revents mask upon processing termination POLLHUP signals. Fixes: f94563fac269 ("perf record: fix poll storm when monitored threads exit") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim

perf record: fix poll storm when monitored threads exit

2026-07-08T05:59:07+00:00

When `perf record` samples a multi-threaded process and one of the target threads exits during the session, perf itself may start burning 100% CPU (up to 200% across two cores) until the session ends. A single dead fd is sufficient to trigger this; it can be reproduced with 15 pthreads in a compute loop where one thread exits halfway through. The root cause is two independent instances of the same defect: dead perf_event ring-buffer fds are left in a pollfd array. When a monitored thread exits, the kernel closes its ring-buffer fd, which then returns POLLHUP. POSIX specifies that poll() always reports POLLHUP and POLLERR regardless of the events mask, so any dead fd left in the array makes poll() return immediately every time, spinning in a tight loop: 3 seconds: 256,600 poll() calls, 0 context switches, only 21 write() Woken up count goes from ~0 to 1,300,000+ There are two affected poll paths, fixed together here: 1. Record main loop, via fdarray__filter() (tools/lib/api/fd/array.c). Since commit 59b4412f27f1 ("libperf: Avoid internal moving of fdarray fds") it only zeroes events/revents without setting fd to -1, so poll() keeps reporting POLLHUP for the entry. Setting fd = -1 makes poll() skip it, matching the pattern already used in the control-fd path at tools/perf/builtin-record.c:1673. 2. BPF sideband thread, perf_evlist__poll_thread() (tools/perf/util/sideband_evlist.c). This thread polls for PERF_RECORD_BPF_EVENT but, unlike the main record loop, never calls fdarray__filter() at all, so dead fds accumulate forever and it spins at 100% CPU: Before fix: dJiffies=101, wchan=0 (running) After fix: dJiffies=0, wchan=do_sys_poll (blocking) Fixed by calling the existing evlist__filter_pollfd() helper after evlist__poll(), mirroring the main record loop. is included for the POLLERR/POLLHUP macros (previously unused there). The two fixes compose: fix 1 makes poll() ignore dead fds (fd=-1); fix 2 ensures the sideband thread actually performs the filtering. Both paths are affected in all kernels from v5.1/v5.9 to the current master (7.2-rc1); the source of both functions is byte-identical across them. BPF event recording is preserved: after the fix, perf.data still contains PERF_RECORD_BPF_EVENT records and bpf_prog_info entries. Verified on perf 6.1.76, 6.6.143 and 7.2-rc1 with a minimal reproducer (Woken up 1,300,000 -> 3, CPU 100% -> 0%) and an A/B orthogonal test: keeping the unpatched binary but preventing the target thread from exiting also makes the storm disappear, confirming the trigger. Fixes: 59b4412f27f1 ("libperf: Avoid internal moving of fdarray fds") Fixes: 657ee5531903 ("perf evlist: Introduce side band thread") Signed-off-by: Jiawei Sun Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim

tools lib api: Fix mount_overload() snprintf truncation and toupper range

2026-06-10T21:56:02+00:00

mount_overload() builds an environment variable name like "PERF_SYSFS_ENVIRONMENT" from fs->name. Two bugs: 1) snprintf() uses name_len as the buffer size instead of sizeof(upper_name). For fs->name = "sysfs" (len=5), the output is truncated to "PERF" (4 chars + null), so getenv() never finds the intended variable. 2) mem_toupper() only uppercases name_len bytes, converting just the "PERF" prefix rather than the full string including the filesystem name portion. Fix by using sizeof(upper_name) for snprintf and strlen(upper_name) for mem_toupper, so the full "PERF_SYSFS_ENVIRONMENT" string is correctly formatted and uppercased. Reported-by: sashiko-bot Fixes: 73ca85ad364769ff ("tools lib api fs: Add FSTYPE__mount() method") Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo

tools lib api: Fix filename__write_int() writing uninitialized stack data

2026-06-10T21:56:01+00:00

filename__write_int() formats an integer into a 64-byte buffer with sprintf() then passes sizeof(buf) (64) as the write length. This writes all 64 bytes including uninitialized stack data past the formatted string. Most sysfs files reject the oversized write, making the function always return -1. Fix by capturing the sprintf() return value and using it as the write length. Reported-by: sashiko-bot Fixes: 3b00ea938653d136 ("tools lib api fs: Add sysfs__write_int function") Cc: Kan Liang Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo

tools lib api: Fix missing null termination in filename__read_int/ull()

2026-06-10T21:56:01+00:00

filename__read_int() passes a stack buffer to read() using the full sizeof(line) and then hands it to atoi() without null-terminating. If a sysfs file fills the 64-byte buffer exactly, atoi() reads past the array into uninitialized stack memory. filename__read_ull_base() has the same issue with strtoull(). Fix both by reading sizeof(line) - 1 bytes and explicitly null-terminating after a successful read. Fixes: 3a351127cbc682c3 ("tools lib fs: Adopt filename__read_int from tools/perf/") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo

libapi: Add missing header with NAME_MAX define to io_dir.h

2025-03-13T07:29:36+00:00

Most systems get this indirectly, but some odd cases (some musl libc systems) can't find it, so just add the header where NAME_MAX is defined to avoid that. Fixes: d118b08f7eee6d6f ("tools lib api: Add io_dir an allocation free readdir alternative") Signed-off-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250310194534.265487-2-acme@kernel.org Signed-off-by: Namhyung Kim

tools lib api: Add io_dir an allocation free readdir alternative

2025-02-24T23:46:33+00:00

glibc's opendir allocates a minimum of 32kb, when called recursively for a directory tree the memory consumption can add up - nearly 300kb during perf start-up when processing modules. Add a stack allocated variant of readdir sized a little more than 1kb. As getdents64 may be missing from libc, add support using syscall. As the system call number maybe missing, add #defines for those. Note, an earlier version of this patch had a feature test for getdents64 but there were problems on certains distros where getdents64 would be #define renamed to getdents breaking the code. The syscall use was made uncondtional to work around this. There is context in: https://lore.kernel.org/lkml/20231207050433.1426834-1-irogers@google.com/ Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250222061015.303622-2-irogers@google.com Signed-off-by: Namhyung Kim

tool api fs: Correctly encode errno for read/write open failures

2024-12-09T20:52:42+00:00

Switch from returning -1 to -errno so that callers can determine types of failure. Reviewed-by: Namhyung Kim Signed-off-by: Ian Rogers Acked-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Athira Rajeev Cc: Ben Gainey Cc: Colin Ian King Cc: Dominique Martinet Cc: Ilkka Koskinen Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Oliver Upton Cc: Paran Lee Cc: Peter Zijlstra Cc: Steinar H. Gunderson Cc: Steven Rostedt (VMware) Cc: Thomas Falcon Cc: Weilin Wang Cc: Yang Jihong Cc: Yang Li Cc: Ze Gao Cc: Zixian Cai Cc: zhaimingbing Link: https://lore.kernel.org/r/20241118225345.889810-3-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo