linux-kernel - Re: [PATCH v8] perf: Sharing PMU counters across compatible 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] [day] [month] [year] [list]

Date:   Thu, 12 Dec 2019 23:49:05 +0000
From:   Song Liu <songliubraving@...com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     open list <linux-kernel@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH v8] perf: Sharing PMU counters across compatible events



> On Dec 12, 2019, at 10:52 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> 
> On Thu, Dec 12, 2019 at 03:45:49PM +0000, Song Liu wrote:
>>> On Dec 12, 2019, at 7:39 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> 
>>> Yuck!
>>> 
>>> Why do you do a full reschedule when you take out a master?
>> 
>> If there is active slave using this master, we need to schedule out
>> them before removing the master. 
>> 
>> We can improve the check though. We only need to do it if the master
>> is in state PERF_EVENT_STATE_ENABLED. 
>> 
>> Or we can add a different function to only schedule out slaves. 
> 
> So I've been thinking, this is because an NMI from another event can
> come in and then does PERF_SAMPLE_READ which covers our event, right?
> 
> AFAICT every other case will run under ctx->lock, which we own at this
> point.

Right, we hold ctx->lock here, so it should be safe in most case. 

> 
> So can't we:
> 
> 1 - stop the current master (such that the counts are frozen)
> 2 - pick the new master
> 3 - initialize the new master (such that the counts match)
> 4 - set the new master on all other events
> 5 - start the new master (counters run again)
> 
> Then, no matter where the NMI lands, it will always find either the old
> or the new master and their counts will match.
> 
> You really don't need to stop all events.

I think this should work. Let me try it. 

Thanks for the suggestion,
Song