All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Rob Herring <robh@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>, Will Deacon <will@kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC] perf/x86: Only expose userspace rdpmc for events on current CPU
Date: Tue, 12 Jan 2021 16:32:30 +0100	[thread overview]
Message-ID: <X/3BDlQxTCYd2HJs@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20210108000136.1556129-1-robh@kernel.org>

On Thu, Jan 07, 2021 at 05:01:36PM -0700, Rob Herring wrote:
> 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.

Don't do that then?

> 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())

Isn't that a nop? That is, from the few sites I checked, we're always
calling this on the event's CPU.

  reply	other threads:[~2021-01-12 15:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08  0:01 [RFC] perf/x86: Only expose userspace rdpmc for events on current CPU Rob Herring
2021-01-12 15:32 ` Peter Zijlstra [this message]
2021-01-12 16:16   ` Rob Herring
2021-01-12 17:03     ` Peter Zijlstra
2021-01-12 20:09       ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X/3BDlQxTCYd2HJs@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=robh@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.