[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aF2H7vICRvqqx8kQ@google.com>
Date: Thu, 26 Jun 2025 10:48:30 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: "Falcon, Thomas" <thomas.falcon@...el.com>
Cc: "alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"acme@...nel.org" <acme@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"mark.rutland@....com" <mark.rutland@....com>,
"Hunter, Adrian" <adrian.hunter@...el.com>,
"irogers@...gle.com" <irogers@...gle.com>,
"jolsa@...nel.org" <jolsa@...nel.org>,
"kan.liang@...ux.intel.com" <kan.liang@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>
Subject: Re: [PATCH v4 2/2] perf top: populate PMU capabilities data in
perf_env
Hello,
On Thu, Jun 26, 2025 at 04:47:18PM +0000, Falcon, Thomas wrote:
> Hi, is there anything still needed from me before this can be accepted?
Sorry I just missed it. I'll add it to the tmp branch for testing.
Thanks,
Namhyung
>
> On Thu, 2025-06-12 at 11:36 -0500, Thomas Falcon wrote:
> > Calling perf top with branch filters enabled on Intel CPU's
> > with branch counters logging (A.K.A LBR event logging [1]) 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
> > ...
> > Thread 27 "perf" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7fffafff76c0 (LWP 949003)]
> > perf_env__find_br_cntr_info (env=0xf66dc0 <perf_env>, nr=0x0, width=0x7fffafff62c0) 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=0xf66dc0 <perf_env>, nr=0x0, width=0x7fffafff62c0) at util/env.c:653
> > #1 0x00000000005b1599 in symbol__account_br_cntr (branch=0x7fffcc3db580, evsel=0xfea2d0, offset=12, br_cntr=8) at util/annotate.c:345
> > #2 0x00000000005b17fb in symbol__account_cycles (addr=5658172, start=5658160, sym=0x7fffcc0ee420, cycles=539, evsel=0xfea2d0, br_cntr=8) at util/annotate.c:389
> > #3 0x00000000005b1976 in addr_map_symbol__account_cycles (ams=0x7fffcd7b01d0, start=0x7fffcd7b02b0, cycles=539, evsel=0xfea2d0, br_cntr=8) at util/annotate.c:422
> > #4 0x000000000068d57f in hist__account_cycles (bs=0x110d288, al=0x7fffafff6540, sample=0x7fffafff6760, nonany_branch_mode=false, total_cycles=0x0, evsel=0xfea2d0) at util/hist.c:2850
> > #5 0x0000000000446216 in hist_iter__top_callback (iter=0x7fffafff6590, al=0x7fffafff6540, single=true, arg=0x7fffffff9e00) at builtin-top.c:737
> > #6 0x0000000000689787 in hist_entry_iter__add (iter=0x7fffafff6590, al=0x7fffafff6540, max_stack_depth=127, arg=0x7fffffff9e00) at util/hist.c:1359
> > #7 0x0000000000446710 in perf_event__process_sample (tool=0x7fffffff9e00, event=0x110d250, evsel=0xfea2d0, sample=0x7fffafff6760, machine=0x108c968) at builtin-top.c:845
> > #8 0x0000000000447735 in deliver_event (qe=0x7fffffffa120, qevent=0x10fc200) at builtin-top.c:1211
> > #9 0x000000000064ccae in do_flush (oe=0x7fffffffa120, show_progress=false) at util/ordered-events.c:245
> > #10 0x000000000064d005 in __ordered_events__flush (oe=0x7fffffffa120, how=OE_FLUSH__TOP, timestamp=0) at util/ordered-events.c:324
> > #11 0x000000000064d0ef in ordered_events__flush (oe=0x7fffffffa120, how=OE_FLUSH__TOP) at util/ordered-events.c:342
> > #12 0x00000000004472a9 in process_thread (arg=0x7fffffff9e00) 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
> >
> > The cause is that perf_env__find_br_cntr_info tries to access a
> > null pointer pmu_caps in the perf_env struct. A similar issue exists
> > for homogeneous core systems which use the cpu_pmu_caps structure.
> >
> > Fix this by populating cpu_pmu_caps and pmu_caps structures with
> > values from sysfs when calling perf top with branch stack sampling
> > enabled.
> >
> > [1], LBR event logging introduced here:
> > https://lore.kernel.org/all/20231025201626.3000228-5-kan.liang@linux.intel.com/
> >
> > Reviewed-by: Ian Rogers <irogers@...gle.com>
> > Signed-off-by: Thomas Falcon <thomas.falcon@...el.com>
> > ---
> > v4: prefer calloc and zfree operations in addition to other
> > cleanups suggested by Namhyung and Arnaldo
> >
> > v3: constify struct perf_pmu *pmu in __perf_env__read_core_pmu_caps()
> > use perf_pmus__find_core_pmu() instead of perf_pmus__scan_core(NULL)
> >
> > v2: update commit message with more meaningful stack trace from
> > gdb and indicate that affected systems are limited to CPU's
> > with LBR event logging support and that both hybrid and
> > non-hybrid core systems are affected.
Powered by blists - more mailing lists