kernel/git/next/linux-next.git/tools/perf/util, branch master

perf metricgroup: Fix metric expression copy leaks

2026-07-11T00:55:16+00:00

metricgroup__copy_metric_events() allocates a new metric expression and duplicates metric_name before linking the expression into the destination metric event. Free new_expr when strdup() fails, and free the duplicated metric_name on the later error paths. Fixes: b85a4d61d302 ("perf metric: Allow modifiers on metrics") Signed-off-by: Yu Peng Signed-off-by: Namhyung Kim

perf capstone: Fix kernel map reference count leak

2026-07-10T00:44:54+00:00

In print_capstone_detail(), maps__find() is used to locate the kernel map. This function increments the reference count of the found map object. However, the current implementation fails to call map__put() after the map is no longer needed, leading to a reference count leak. Fix this by adding a map__put(map) call to properly release the reference after use. Fixes: 92dfc59463d5 ("perf annotate: Add symbol name when using capstone") Signed-off-by: Tengda Wu Signed-off-by: Namhyung Kim

perf dso: Fix kallsyms DSO detection with fallback logic

2026-07-09T00:00:52+00:00

The current kallsyms detection in dso__is_kallsyms() uses the dso_binary_type enum which fixes the issue of kallsyms being cached in the build-id cache for out-of-tree modules. However, during build-id injection in perf record/inject, dso_binary_type has not been explicitly set yet,so dso__binary_type() returns DSO_BINARY_TYPE__NOT_FOUND instead of DSO_BINARY_TYPE__KALLSYMS for the kernel DSO. The current check then fails to identify it as kallsyms, causing build-id symlinks to not be created in ~/.debug/.build-id/ and perf archive to fail with "Cannot stat" errors. Steps to reproduce the issue: 1. rm -rf ~/.debug/.build-id 2. perf record sleep 1 3. perf archive Fix by falling back to matching long_name against the known kallsyms strings explicitly when binary_type is not yet set (== DSO_BINARY_TYPE__NOT_FOUND). Use strcmp() for exact matching of fixed names and strict validation for guest kallsyms with embedded PID to prevent path traversal attacks. Fixes: ebf0b332732d ("perf dso: fix dso__is_kallsyms() check") Signed-off-by: Tanushree Shah Signed-off-by: Namhyung Kim

perf data convert json: Fix trace_seq memory leak in process_sample_event()

2026-07-08T06:04:21+00:00

Unlike the in-kernel trace_seq which uses a statically allocated buffer, the userspace traceevent library's trace_seq uses a dynamically allocated one. Therefore, every trace_seq_init() call must be paired with a trace_seq_destroy(), otherwise it produces a memory leak. In process_sample_event(), a trace_seq is initialized for each field when formatting tracepoint raw_data, but the matching trace_seq_destroy() is never called, leaking memory for every field of every sample processed. Add the missing trace_seq_destroy() after using the trace_seq buffer to properly free the allocated memory. Detected with Valgrind on a perf.data file with 2,729 tracepoint samples: Before: definitely lost: 55,537,664 bytes in 13,559 blocks After: definitely lost: 0 bytes in 0 blocks Fixes: 9d895e468429 ("perf data: Add tracepoint fields when converting to JSON") Signed-off-by: Tanushree Shah 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

perf cs-etm: Synthesize callchains for instruction samples

2026-07-03T23:51:59+00:00

CS ETM already records branches into the thread stack, but instruction samples do not carry synthesized callchains. It misses to support the callchain and no output with the itrace option 'g'. Allocate a callchain buffer per queue and use thread_stack__sample() when synthesizing instruction samples. Advertise PERF_SAMPLE_CALLCHAIN on the synthetic instruction event. Allocate one extra callchain entry than requested, as the first entry is reserved for storing context information. cs_etm__context() is introduced for handling context packet and update the thread info and start kernel address for frontend decoding. After: perf script --itrace=g16l64i1i callchain_test 6543 [002] 1 instructions: ffff800080010c14 vectors+0x414 ([kernel.kallsyms]) aaaad6b60784 do_svc+0x1c (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaad6b60798 print+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaad6b607b0 foo+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaad6b607c8 main+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) ffff9325225c __libc_start_call_main+0x7c (/usr/lib/aarch64-linux-gnu/libc.so.6) ffff9325233c call_init+0x9c (inlined) ffff9325233c __libc_start_main_impl+0x9c (inlined) aaaad6b60670 _start+0x30 (/home/kernel/leoy/test_cs_callchain/callchain_test) ffff800080012290 ret_to_user+0x120 ([kernel.kallsyms]) Signed-off-by: Leo Yan Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim

perf cs-etm: Support call indentation

2026-07-03T23:51:59+00:00

The perf script callindent is derived from call stack in thread context, CS ETM ignores the requirement for callindent without pushing and poping call stack. Enable thread-stack when either itrace thread-stack support or last branch entries are requested, allocate the branch stack storage accordingly, and feed taken branches to thread_stack__event() whenever thread-stack state is needed. When callindent is requested, pass callstack=true to thread_stack__event() so the common thread-stack code maintains call depth for branch samples. Before: perf script -F +callindent callchain_test 6543 [002] 1 branches: main ffff93252258 __libc_start_call_main+0x78 (/usr/lib/aarch64-linux-gnu/libc.so.6) callchain_test 6543 [002] 1 branches: foo aaaad6b607c4 main+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 6543 [002] 1 branches: print aaaad6b607ac foo+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 6543 [002] 1 branches: do_svc aaaad6b60794 print+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 6543 [002] 1 branches: vectors aaaad6b60780 do_svc+0x18 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 6543 [002] 1 branches: el0t_64_sync_handler ffff80008001159c el0t_64_sync+0x194 ([kernel.kallsyms]) callchain_test 6543 [002] 1 branches: el0_svc ffff800081829194 el0t_64_sync_handler+0x9c ([kernel.kallsyms]) callchain_test 6543 [002] 1 branches: lockdep_hardirqs_off ffff800081828794 el0_svc+0x24 ([kernel.kallsyms]) callchain_test 6543 [002] 1 branches: __this_cpu_preempt_check ffff80008182b348 lockdep_hardirqs_off+0xf0 ([kernel.kallsyms]) After: callchain_test 6543 [002] 1 branches: main ffff93252258 __libc_start_call_main+0x78 (/usr/lib/aarch64-linux-gnu/libc.so.6) callchain_test 6543 [002] 1 branches: foo aaaad6b607c4 main+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 6543 [002] 1 branches: print aaaad6b607ac foo+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 6543 [002] 1 branches: do_svc aaaad6b60794 print+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 6543 [002] 1 branches: vectors aaaad6b60780 do_svc+0x18 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 6543 [002] 1 branches: el0t_64_sync_handler ffff80008001159c el0t_64_sync+0x194 ([kernel.kallsyms]) callchain_test 6543 [002] 1 branches: el0_svc ffff800081829194 el0t_64_sync_handler+0x9c ([kernel.kallsyms]) callchain_test 6543 [002] 1 branches: lockdep_hardirqs_off ffff800081828794 el0_svc+0x24 ([kernel.kallsyms]) callchain_test 6543 [002] 1 branches: __this_cpu_preempt_check ffff80008182b348 lockdep_hardirqs_off+0xf0 ([kernel.kallsyms]) Signed-off-by: Leo Yan Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim

perf cs-etm: Flush thread stacks after decoder reset

2026-07-03T23:51:59+00:00

Perf resets the CoreSight decoder when moving to a new AUX trace buffer, this causes trace discontinunity globally. For callchain synthesis, keeping thread-stack state after decoder reset can leave stale call/return history attached to threads that are decoded later, producing incorrect synthesized callchains. Flush all host thread stacks after a decoder reset. When virtualization is present, flush the guest thread stacks as well. Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim

perf cs-etm: Use thread-stack for last branch entries

2026-07-03T23:51:59+00:00

CS ETM maintains its own circular array for last branch entries, with local helpers to update, copy and reset the branch stack. This duplicates logic already provided by the common code. Record taken branches with thread_stack__event() and synthesize PERF_SAMPLE_BRANCH_STACK data with thread_stack__br_sample(). This removes the private last_branch_rb buffer and its position tracking. This also makes the branch history state belong to the thread rather than the trace queue. That is a better fit for CoreSight traces where a trace queue can effectively be CPU scoped, while call/return history is per thread. Keep the buffer number updated via thread_stack__set_trace_nr(), which is used when exporting samples to Python scripts. Pass callstack=false for now; synthesized callchains are added by a later patch. The output should remain same, except that be->flags.predicted is no longer set. Since CoreSight trace does not provide branch prediction information, clearing the flag avoids confusion. Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim

perf cs-etm: Refactor instruction size handling

2026-07-03T23:51:59+00:00

This patch introduces a new function cs_etm__instr_size() to calculate the instruction size based on ISA type and instruction address. Given the trace data can be MB and most likely that will be A64/A32 on a lot of platforms, cs_etm__instr_addr() keeps a single ISA type check for A64/A32 and executes an optimized calculation (addr + offset * 4). Signed-off-by: Leo Yan Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim