linux-kernel - Re: [PATCH v3 7/8] perf: Add perf_event

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_JsqKJYrEUzkzNMKMOGvzJN_EqacHZvBR6eVt35bRhhtRo=g@mail.gmail.com>
Date:   Mon, 28 Nov 2022 11:15:21 -0600
From:   Rob Herring <robh@...nel.org>
To:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:     Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Marc Zyngier <maz@...nel.org>,
        Oliver Upton <oliver.upton@...ux.dev>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        James Morse <james.morse@....com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        kvmarm@...ts.linux.dev, linux-perf-users@...r.kernel.org,
        linux-kernel@...r.kernel.org, James Clark <james.clark@....com>,
        Mark Brown <broonie@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu
Subject: Re: [PATCH v3 7/8] perf: Add perf_event_attr::config3

On Mon, Nov 28, 2022 at 10:36 AM Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
>
> Rob Herring <robh@...nel.org> writes:
>
> > On Fri, Nov 18, 2022 at 10:49 AM Will Deacon <will@...nel.org> wrote:
> >>
> >> On Fri, Nov 04, 2022 at 10:55:07AM -0500, Rob Herring wrote:
> >> > @@ -515,6 +516,8 @@ struct perf_event_attr {
> >> >        * truncated accordingly on 32 bit architectures.
> >> >        */
> >> >       __u64   sig_data;
> >> > +
> >> > +     __u64   config3; /* extension of config2 */
> >>
> >> I need an ack from the perf core maintainers before I can take this.
> >
> > Peter, Arnaldo, Ingo,
> >
> > Can I get an ack on this please.
>
> It appears that PMUs that don't use config{1,2} and now config3 allow
> them to be whatever without any validation, whereas in reality we should
> probably -EINVAL in those cases. Should something be done about that?

Always the 3rd occurrence that gets to clean-up things. ;)

I think we'd have to add some capability flags for PMU drivers to set
to enable configN usage and then use those to validate configN is 0.
Wouldn't be too hard to do for config3 as we know there's exactly 1
user, but for 1,2 there's about 80 PMU drivers to check.

Rob