[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38a45f2b-b47a-fccd-2c87-3a46502202a4@linux.intel.com>
Date: Fri, 28 Sep 2018 09:57:37 +0100
From: Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>
To: Andi Kleen <ak@...ux.intel.com>,
Tvrtko Ursulin <tursulin@...ulin.net>
Cc: linux-kernel@...r.kernel.org,
Tvrtko Ursulin <tvrtko.ursulin@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Madhavan Srinivasan <maddy@...ux.vnet.ibm.com>,
Alexey Budankov <alexey.budankov@...ux.intel.com>,
x86@...nel.org
Subject: Re: [RFC 3/5] perf: Allow per PMU access control
On 27/09/2018 21:15, Andi Kleen wrote:
>> + mutex_lock(&pmus_lock);
>> + list_for_each_entry(pmu, &pmus, entry)
>> + pmu->perf_event_paranoid = sysctl_perf_event_paranoid;
>> + mutex_unlock(&pmus_lock);
>
> What happens to pmus that got added later?
There is a hunk a bit lower in the patch where in perf_pmu_register the
initial setting is assigned from the global sysctl.
> The rest looks good.
>
> Can you post a non RFC version?
Sure!
Regards,
Tvrtko
Powered by blists - more mailing lists