linux-kernel - Re: [PATCH] perf: arm_pmuv3: Avoid assigning fixed cycle counter with threshold

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: <CAL_JsqLXL12cLtP=BBiMw3dn0ZqPWmc76ey8LziDdSDyhuGh-g@mail.gmail.com>
Date: Mon, 24 Jun 2024 10:58:01 -0600
From: Rob Herring <robh@...nel.org>
To: James Clark <james.clark@....com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] perf: arm_pmuv3: Avoid assigning fixed cycle counter with threshold

On Tue, Jun 18, 2024 at 10:30 AM James Clark <james.clark@....com> wrote:
>
>
>
> On 11/06/2024 17:13, James Clark wrote:
> >
> >
> > On 11/06/2024 16:50, Rob Herring (Arm) wrote:
> >> If the user has requested a counting threshold for the CPU cycles event,
> >> then the fixed cycle counter can't be assigned as it lacks threshold
> >> support. Currently, the thresholds will work or not randomly depending
> >> on which counter the event is assigned.
> >>
> >> While using thresholds for CPU cycles doesn't make much sense, it can be
> >> useful for testing purposes.
> >>
> >> Fixes: 816c26754447 ("arm64: perf: Add support for event counting threshold")
> >> Signed-off-by: Rob Herring (Arm) <robh@...nel.org>
> >> ---
> >>  drivers/perf/arm_pmuv3.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> >> index 23fa6c5da82c..2612be29ee23 100644
> >> --- a/drivers/perf/arm_pmuv3.c
> >> +++ b/drivers/perf/arm_pmuv3.c
> >> @@ -939,9 +939,10 @@ static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc,
> >>      struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> >>      struct hw_perf_event *hwc = &event->hw;
> >>      unsigned long evtype = hwc->config_base & ARMV8_PMU_EVTYPE_EVENT;
> >> +    bool has_threshold = !!(hwc->config_base & ARMV8_PMU_EVTYPE_TH);
> >
> > I was going to say doesn't it need to be (ARMV8_PMU_EVTYPE_TH |
> > ARMV8_PMU_EVTYPE_TC) for it to give the same results as the hardware.
> > But then I saw we only enable it if TH != 0, even if TC is set. And now
> > I'm wondering if I inadvertently disabled a useful combination of options.
> >
> > The Arm ARM says it's only completely disabled when both TC and TH are 0.
> >
>
> If it's easy it might be worth adding a helper function for
> has_threshold() that's used in both places. That way if or when this
> issue gets fixed up it doesn't break here.

The other place being in armv8pmu_set_event_filter()? A helper doesn't
help there because that looks at the attr value, not config_base.

Rob