linux-kernel - Re: [PATCH v3 00/15] Legacy hardware/cache events as json

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP-5=fVbtL=eL5bCFzz06g86Sk3nBsxUmgwZ3c5UY7z5hwmoLA@mail.gmail.com>
Date: Wed, 10 Sep 2025 08:00:22 -0700
From: Ian Rogers <irogers@...gle.com>
To: James Clark <james.clark@...aro.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>, 
	Xu Yang <xu.yang_2@....com>, Thomas Falcon <thomas.falcon@...el.com>, 
	Andi Kleen <ak@...ux.intel.com>, linux-kernel@...r.kernel.org, 
	linux-perf-users@...r.kernel.org, bpf@...r.kernel.org, 
	Atish Patra <atishp@...osinc.com>, Beeman Strong <beeman@...osinc.com>, Leo Yan <leo.yan@....com>, 
	Vince Weaver <vincent.weaver@...ne.edu>
Subject: Re: [PATCH v3 00/15] Legacy hardware/cache events as json

On Wed, Sep 10, 2025 at 4:14 AM James Clark <james.clark@...aro.org> wrote:
>
> On 28/08/2025 9:59 pm, Ian Rogers wrote:
> > Mirroring similar work for software events in commit 6e9fa4131abb
> > ("perf parse-events: Remove non-json software events"). These changes
> > migrate the legacy hardware and cache events to json.  With no hard
> > coded legacy hardware or cache events the wild card, case
> > insensitivity, etc. is consistent for events. This does, however, mean
> > events like cycles will wild card against all PMUs. A change doing the
> > same was originally posted and merged from:
> > https://lore.kernel.org/r/20240416061533.921723-10-irogers@google.com
> > and reverted by Linus in commit 4f1b067359ac ("Revert "perf
> > parse-events: Prefer sysfs/JSON hardware events over legacy"") due to
> > his dislike for the cycles behavior on ARM with perf record. Earlier
> > patches in this series make perf record event opening failures
> > non-fatal and hide the cycles event's failure to open on ARM in perf
> > record, so it is expected the behavior will now be transparent in perf
> > record on ARM. perf stat with a cycles event will wildcard open the
> > event on all PMUs.
>
> Hi Ian,
>
> Briefly testing perf record and perf stat seem to work now. i.e "perf
> record -e cycles" doesn't fail and just skips the uncore cycles event.
> And "perf stat" now includes the uncore cycles event which I think is
> harmless.

Thanks for confirming this.

> But there are a few perf test failures. For example "test event parsing":
>
>    evlist after sorting/fixing: 'arm_cmn_0/cycles/,{cycles,cache-
>      misses,branch-misses}'
>    FAILED tests/parse-events.c:1589 wrong number of entries
>    Event test failure: test 57 '{cycles,cache-misses,branch-
>      misses}:e'running test 58 'cycles/name=name/'

I suspect the easiest fix for this is to change "cycles" to the
"cpu-cycles" legacy hardware event for this test. The test has always
had issues on ARM due to hardcoded expectations of the core PMU being
"cpu".

> The tests "Perf time to TSC" and "Use a dummy software event to keep
> tracking" are using libperf to open the cycles event as a sampling event
> which now fails. It seems like we've fixed Perf record to ignore this
> failure, but we didn't think about libperf until now.

I'm not clear on the connection here. libperf doesn't do event parsing
and so there are no changes in tools/lib/perf. If a test has an
expectation that "cycles" is a core event, again we can change it to
"cpu-cycles" as a workaround for ARM. As "cycles" will wildcard now,
we don't want that behavior in say API probing as we'll end up never
lazily processing the PMUs. That code has been altered in these
changes to specify the core PMU. For tests it is less of an issue and
so the changes are more limited.

Thanks,
Ian