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: <20170530185300.ej763qvmsw5aldhg@hirez.programming.kicks-ass.net>
Date:   Tue, 30 May 2017 20:53:00 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Vince Weaver <vince@...ter.net>
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, May 30, 2017 at 01:55:33PM -0400, Vince Weaver wrote:
> 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....

No, anything PERF_SAMPLE_READ (group or not) on inherited events is
wrong.

It would only report the event count of the current task count + all
dead child counts (if you hit the parent event). It would not include
the current count of any other live tasks in the hierarchy.

And the problem is that fixing this is rather tricky and iterating the
hierarchy can be excessively expensive in any case (imagine having to
iterate several hundred tasks tasks from that NMI/interrupt).

And since its from NMI/interrupt context it is impossible to get the
current count of any other live tasks that are running on another CPU.

> perf_event_open() would let 
> you do this even though the results would probably be wrong?

Right, currently we have the filter on PERF_FORMAT_GROUP, but it should
be PERF_SAMPLE_READ.

So a !group SAMPLE_READ on inherited is currently allowed but returns
'interesting' values.