linux-kernel - Re: perf group read for inherited events

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: <alpine.DEB.2.11.1705301348240.5050@pianoman.cluster.toy>
Date:   Tue, 30 May 2017 13:55:33 -0400 (EDT)
From:   Vince Weaver <vince@...ter.net>
To:     Peter Zijlstra <peterz@...radead.org>
cc:     Andi Kleen <ak@...ux.intel.com>, linux-kernel@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Stephane Eranian <eranian@...gle.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>
Subject: Re: perf group read for inherited events

On Tue, 30 May 2017, Peter Zijlstra wrote:

> On Tue, May 30, 2017 at 06:57:14AM -0700, Andi Kleen wrote:
> > On Tue, May 30, 2017 at 11:45:12AM +0200, Peter Zijlstra wrote:
> > > > Or is the simple patch below good enough?
> > > 
> > > The below seems to be the correct thing. It is rather unfortunate that
> > > this would break/significantly change existing semantics :/
> > 
> > The "existing semantics" as in ignoring the PERF_SAMPLE_READ in sample_type,
> > even though it wasn't implemented? It seems reasonable to me.
> 
> Right, so where we used to accept PERF_SAMPLE_READ on inherited events,
> we now no longer will.
> 
> Note that it currently doesn't work right, even if it doesn't fail like
> with the proposed patch.
> 
> Typically Vince will (rightly) complain when I change things like this.
> But seeing how even if we accept it, it is fairly terminally buggered in
> any case, we could change it.
> 
> Vince, do you know of anybody that would be immediately affected by
> this?

I often only hear about breakage months later after it's too late.

So the issue is currently if you were sampling, and you were sampling on
an event group, and you had set PERF_SAMPLE_READ to get all counts for a 
group, and the event was also inherited.... perf_event_open() would let 
you do this even though the results would probably be wrong?

I'm not aware of anyone trying to do this, or at least I should say PAPI 
isn't trying to do this (PAPI currently has pretty simplistic sampling 
support, though that's getting a major overhaul this summer).

Vince