[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210108000136.1556129-1-robh@kernel.org>
Date: Thu, 7 Jan 2021 17:01:36 -0700
From: Rob Herring <robh@...nel.org>
To: Jiri Olsa <jolsa@...hat.com>
Cc: Will Deacon <will@...nel.org>, Andy Lutomirski <luto@...nel.org>,
linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Namhyung Kim <namhyung@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>
Subject: [RFC] perf/x86: Only expose userspace rdpmc for events on current CPU
Userspace access using rdpmc only makes sense if the event is valid for
the current CPU. However, cap_user_rdpmc is currently set no matter which
CPU the event is associated with. The result is userspace reading another
CPU's event thinks it can use rdpmc to read the counter. In doing so, the
wrong counter will be read.
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>
Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc: Jiri Olsa <jolsa@...hat.com>
Cc: Namhyung Kim <namhyung@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org
Cc: "H. Peter Anvin" <hpa@...or.com>
Signed-off-by: Rob Herring <robh@...nel.org>
---
I'm working on adding userspace counter access for arm64 along with a
common access routine in libperf. I found this issue when testing per CPU
events. More details are here[1].
I'm going to need the same thing for arm64. This could possibly go into
perf_event_update_userpage() instead, but perhaps there could be an arch
where userspace can read other cpu's counters.
What's the ABI between libperf and kernel versions? This change will
only help the libperf implementation if libperf doesn't need to support
old kernels.
[1] https://lore.kernel.org/r/CAL_JsqJzeCebq4VP+xBtfh=fbomvaJoVMp35AQQDGTYD-fRWgw@mail.gmail.com
---
arch/x86/events/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index a88c94d65693..6e6d4c1d03ca 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2490,7 +2490,8 @@ void arch_perf_update_userpage(struct perf_event *event,
userpg->cap_user_time = 0;
userpg->cap_user_time_zero = 0;
userpg->cap_user_rdpmc =
- !!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED);
+ !!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED) &&
+ (event->oncpu == smp_processor_id());
userpg->pmc_width = x86_pmu.cntval_bits;
if (!using_native_sched_clock() || !sched_clock_stable())
--
2.27.0
Powered by blists - more mailing lists