linux-kernel - Re: [REGRESSION] Perf (userspace) broken on big.LITTLE systems since v6.5

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: <ZV-ItX1eMeIdo_00@FVFF77S0Q05N.cambridge.arm.com>
Date:   Thu, 23 Nov 2023 17:15:33 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     James Clark <james.clark@....com>
Cc:     Ian Rogers <irogers@...gle.com>, Marc Zyngier <maz@...nel.org>,
        Hector Martin <marcan@...can.st>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        linux-perf-users@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Asahi Linux <asahi@...ts.linux.dev>
Subject: Re: [REGRESSION] Perf (userspace) broken on big.LITTLE systems since
 v6.5

On Thu, Nov 23, 2023 at 05:08:43PM +0000, James Clark wrote:
> On 23/11/2023 16:48, Mark Rutland wrote:
> > Ah, so IIUC what's happening is:
> > 
> > 1) Userspace tries to detect extended type support, with a cycles event
> >    directed to one of the CPU PMUs. The attr for this does not have
> >    exclude_guest set.
> > 
> > 2) In the kernel, the core perf code sees the extended hw type id, and directs
> >    this towards the correct PMU (apple_icestorm_pmu).
> > 
> > 3) The PMU driver looks at the attr, sees exclude_guest is not set, and returns
> >    -EOPNOTSUPP, exactly as it would regardless of whether the extended hw type
> >    is used.
> > 
> >    Note: this happens to be a difference between x86 PMUs and the apple_* PMUs,
> >    but this is a legitimate part of the perf ABI, not an arm-specific quirk or
> >    bug.
> > 
> > 4) Userspace receives -EOPNOTSUPP, and so decide the extended hw_type is not
> >    supported (even though the kernel does support the extended hw type id, and
> >    the event was rejected for orthogonal reasons).

> > It sounds like we need to make (4) more robust? I'm not immediately sure how, 
> > given the rats nest of returns in perf_event_open(), but I'm happy to try to
> > help with that.
> 
> It might be worth reporting extended HW ID support in the caps folder of
> the PMU so that Perf can look there instead of trying to open the event.
> It's something that we know will always be on or always be off so it
> doesn't make sense to try to discover it by opening an event.

Yep, I'm open to that idea. I'm more than happy to expose something that
indicates "this PMU supports the extended HW ID" and/or "this kernel supports
the extended HW ID".

Given that the actual PMU drivers don't see the extended cap, and that's
handled by the core, I'd like to make the core logic unconditional and remove
the kernel-internal PERF_PMU_CAP_EXTENDED_HW_TYPE cap. So I'd lean towards the
"this kernel supports the extended HW ID" option.

Thanks,
Mark.