| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <644107dbbae586096302f0bdfabd90955322bd2c.camel@intel.com>
Date: Tue, 6 May 2025 18:52:42 +0000
From: "Falcon, Thomas" <thomas.falcon@...el.com>
To: "acme@...nel.org" <acme@...nel.org>
CC: "alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
"peterz@...radead.org" <peterz@...radead.org>, "kan.liang@...ux.intel.com"
<kan.liang@...ux.intel.com>, "linux-perf-users@...r.kernel.org"
<linux-perf-users@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
"Hunter, Adrian" <adrian.hunter@...el.com>, "namhyung@...nel.org"
<namhyung@...nel.org>, "jolsa@...nel.org" <jolsa@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"irogers@...gle.com" <irogers@...gle.com>, "mark.rutland@....com"
<mark.rutland@....com>
Subject: Re: [PATCH] perf top: populate PMU capabilities data in perf_env
On Tue, 2025-05-06 at 13:56 -0300, Arnaldo Carvalho de Melo wrote:
> On Tue, May 06, 2025 at 04:09:37PM +0000, Falcon, Thomas wrote:
> > On Thu, 2025-05-01 at 20:46 +0000, Falcon, Thomas wrote:
> > > On Thu, 2025-05-01 at 13:00 -0700, Ian Rogers wrote:
> > > > On Thu, May 1, 2025 at 11:42 AM Thomas Falcon <thomas.falcon@...el.com> wrote:
> > > > > Calling perf top with brach filters enabled on Intel hybrid CPU's
> > > > > with branch counter event logging support results in a segfault.
>
> > > > > $ ./perf top -e '{cpu_core/cpu-cycles/,cpu_core/event=0xc6,umask=0x3,\
> > > > > frontend=0x11,name=frontend_retired_dsb_miss/}' -j any,counter
> > > > > perf: Segmentation fault
> > > > > -------- backtrace --------
> > > > > ./perf() [0x55f460]
> > > > > /lib64/libc.so.6(+0x1a050) [0x7fd8be227050]
> > > > > ./perf() [0x57b4a7]
> > > > > ./perf() [0x561e5a]
> > > > > ./perf() [0x604a81]
> > > > > ./perf() [0x4395b5]
> > > > > ./perf() [0x601732]
> > > > > ./perf() [0x439bc1]
> > > > > ./perf() [0x5d35b3]
> > > > > ./perf() [0x43936c]
> > > > > /lib64/libc.so.6(+0x70ba8) [0x7fd8be27dba8]
> > > > > /lib64/libc.so.6(+0xf4b8c) [0x7fd8be301b8c]
>
> > > Hi Ian, thanks for reviewing.
>
> > > > Thanks Thomas. Could you generate this backtrace in GDB? I did write a
> > > > patch to symbolize backtraces like this:
> > > > https://lore.kernel.org/lkml/20250313052952.871958-2-irogers@google.com/
> > > > Sadly without any reviewed tags and unmerged - the code calls routines
> > > > that malloc so it isn't strictly sound if say the backtrace was needed
> > > > from a SEGV in the malloc implementation, it is nicely
> > > > self-referencing the perf APIs, ..
>
> > > Sorry about that, here is the backtrace I'm seeing when running the perf top command in gdb:
>
> > > Thread 27 "perf" received signal SIGSEGV, Segmentation fault.
>
> > > [Switching to Thread 0x7fffcb7fe6c0 (LWP 812169)]
> > > 0x000000000057b4a7 in perf_env.find_br_cntr_info ()
> > > (gdb) backtrace
> > > #0 0x000000000057b4a7 in perf_env.find_br_cntr_info ()
> > > #1 0x0000000000561e5a in addr_map_symbol.account_cycles ()
> > > #2 0x0000000000604a81 in hist.account_cycles ()
> > > #3 0x00000000004395b5 in hist_iter.top_callback ()
> > > #4 0x0000000000601732 in hist_entry_iter.add ()
> > > #5 0x0000000000439bc1 in deliver_event ()
> > > #6 0x00000000005d35b3 in __ordered_events__flush ()
> > > #7 0x000000000043936c in process_thread ()
> > > #8 0x00007ffff6e7dba8 in start_thread (arg=<optimized out>) at pthread_create.c:448
> > > #9 0x00007ffff6f01b8c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
>
> > Sorry, let me try this again...
>
> > Thread 27 "perf" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7fffcf7fe6c0 (LWP 940046)]
> > perf_env__find_br_cntr_info (env=0xf328c0 <perf_env>, nr=0x0, width=0x7fffcf7fd2c0) at util/env.c:653
> > 653 *width = env->cpu_pmu_caps ? env->br_cntr_width :
> > (gdb) bt
> > #0 perf_env__find_br_cntr_info (env=0xf328c0 <perf_env>, nr=0x0, width=0x7fffcf7fd2c0) at util/env.c:653
> > #1 0x00000000005ad829 in symbol__account_br_cntr (branch=0x7fffd11f9c00, evsel=0xfae480, offset=20, br_cntr=4) at util/annotate.c:345
> > #2 0x00000000005ada8b in symbol__account_cycles (addr=5580436, start=5580433, sym=0x7fffd00d3010, cycles=1, evsel=0xfae480, br_cntr=4) at util/annotate.c:389
> > #3 0x00000000005adc06 in addr_map_symbol__account_cycles (ams=0x7fffd17b1e20, start=0x7fffd17b1f00, cycles=1, evsel=0xfae480, br_cntr=4) at util/annotate.c:422
> > #4 0x0000000000688ab4 in hist__account_cycles (bs=0x10cbaa8, al=0x7fffcf7fd540, sample=0x7fffcf7fd760, nonany_branch_mode=false, total_cycles=0x0, evsel=0xfae480) at util/hist.c:2774
> > #5 0x0000000000446004 in hist_iter__top_callback (iter=0x7fffcf7fd590, al=0x7fffcf7fd540, single=true, arg=0x7fffffff9de0) at builtin-top.c:737
> > #6 0x0000000000684d2a in hist_entry_iter__add (iter=0x7fffcf7fd590, al=0x7fffcf7fd540, max_stack_depth=127, arg=0x7fffffff9de0) at util/hist.c:1291
> > #7 0x00000000004464fe in perf_event__process_sample (tool=0x7fffffff9de0, event=0x10cba70, evsel=0xfae480, sample=0x7fffcf7fd760, machine=0x105ec68) at builtin-top.c:845
> > #8 0x0000000000447523 in deliver_event (qe=0x7fffffffa0f8, qevent=0x10cdd60) at builtin-top.c:1211
> > #9 0x0000000000648aff in do_flush (oe=0x7fffffffa0f8, show_progress=false) at util/ordered-events.c:245
> > #10 0x0000000000648e56 in __ordered_events__flush (oe=0x7fffffffa0f8, how=OE_FLUSH__TOP, timestamp=0) at util/ordered-events.c:324
> > #11 0x0000000000648f40 in ordered_events__flush (oe=0x7fffffffa0f8, how=OE_FLUSH__TOP) at util/ordered-events.c:342
> > #12 0x0000000000447097 in process_thread (arg=0x7fffffff9de0) at builtin-top.c:1120
> > #13 0x00007ffff6e7dba8 in start_thread (arg=<optimized out>) at pthread_create.c:448
> > #14 0x00007ffff6f01b8c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
>
> I'll test on a 14700 later today, but on this one it is working:
>
> root@x1:~# grep -m1 "model name" /proc/cpuinfo
> model name : 13th Gen Intel(R) Core(TM) i7-1365U
> root@x1:~# perf -vv
> perf version 6.15.rc2.g8feafba59c51
> aio: [ on ] # HAVE_AIO_SUPPORT
> bpf: [ on ] # HAVE_LIBBPF_SUPPORT
> bpf_skeletons: [ on ] # HAVE_BPF_SKEL
> debuginfod: [ on ] # HAVE_DEBUGINFOD_SUPPORT
> dwarf: [ on ] # HAVE_LIBDW_SUPPORT
> dwarf_getlocations: [ on ] # HAVE_LIBDW_SUPPORT
> dwarf-unwind: [ on ] # HAVE_DWARF_UNWIND_SUPPORT
> auxtrace: [ on ] # HAVE_AUXTRACE_SUPPORT
> libbfd: [ OFF ] # HAVE_LIBBFD_SUPPORT ( tip: Deprecated, license incompatibility, use BUILD_NONDISTRO=1 and install binutils-dev[el] )
> libcapstone: [ on ] # HAVE_LIBCAPSTONE_SUPPORT
> libcrypto: [ on ] # HAVE_LIBCRYPTO_SUPPORT
> libdw-dwarf-unwind: [ on ] # HAVE_LIBDW_SUPPORT
> libelf: [ on ] # HAVE_LIBELF_SUPPORT
> libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT
> libopencsd: [ on ] # HAVE_CSTRACE_SUPPORT
> libperl: [ on ] # HAVE_LIBPERL_SUPPORT
> libpfm4: [ on ] # HAVE_LIBPFM
> libpython: [ on ] # HAVE_LIBPYTHON_SUPPORT
> libslang: [ on ] # HAVE_SLANG_SUPPORT
> libtraceevent: [ on ] # HAVE_LIBTRACEEVENT
> libunwind: [ OFF ] # HAVE_LIBUNWIND_SUPPORT ( tip: Deprecated, use LIBUNWIND=1 and install libunwind-dev[el] to build with it )
> lzma: [ on ] # HAVE_LZMA_SUPPORT
> numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT
> zlib: [ on ] # HAVE_ZLIB_SUPPORT
> zstd: [ on ] # HAVE_ZSTD_SUPPORT
> root@x1:~# perf top -e '{cpu_core/cpu-cycles/,cpu_core/event=0xc6,umask=0x3,frontend=0x11,name=frontend_retired_dsb_miss/}' -j any,counte
>
I should have been clearer in my commit message but it requires PMU's with "branch_counter_nr" and
"branch_counter_width" capabilities to recreate.
$ ls /sys/devices/cpu_core/caps
branch_counter_nr branch_counter_width branches max_precise pmu_name
$ sudo perf top -e '{cpu_core/cpu-
cycles/,cpu_core/event=0xc6,umask=0x3,frontend=0x11,name=frontend_retired_dsb_miss/}' -j any,counter
perf: Segmentation fault
-------- backtrace --------
perf(+0xfa734) [0x561b5b19f734]
/lib64/libc.so.6(+0x1a050) [0x7faa77a27050]
perf(perf_env__find_br_cntr_info+0x77) [0x561b5b1b8377]
perf(addr_map_symbol__account_cycles+0x22e) [0x561b5b1a27de]
perf(hist__account_cycles+0x241) [0x561b5b23dae1]
perf(+0x2c459) [0x561b5b0d1459]
perf(hist_entry_iter__add+0xe2) [0x561b5b239a32]
perf(+0x2ca08) [0x561b5b0d1a08]
perf(+0x168373) [0x561b5b20d373]
perf(+0x2c214) [0x561b5b0d1214]
/lib64/libc.so.6(+0x71168) [0x7faa77a7e168]
/lib64/libc.so.6(+0xf514c) [0x7faa77b0214c]
Thanks,
Tom
> Add --off-cpu-thresh option
> 74069a01609ef0f4 perf record --off-cpu: Dump the remaining PERF_SAMPLE_ in sample_type from BPF's stack trace map
> 8ae7a5769b0a3ac2 perf script: Display off-cpu samples correctly
> 7de1a87f1ee75743 perf record --off-cpu: Disable perf_event's callchain collection
> 7f8f56475d585117 perf evsel: Assemble off-cpu samples
> d6948f2af24e04ea perf record --off-cpu: Dump off-cpu samples in BPF
> 282c195906c76ddf perf record --off-cpu: Preparation of off-cpu BPF program
> 0f72027bb9fb77a2 perf record --off-cpu: Parse off-cpu event
> 671e943452b18001 perf evsel: Expose evsel__is_offcpu_event() for future use
> ⬢ [acme@...lbx perf-tools-next]$
>
> - Arnaldo
Powered by blists - more mailing lists