LKML Archive on
 help / color / Atom feed
From: Andy Lutomirski <>
To: Hillf Danton <>
Cc: Peter Zijlstra <>,
	Ingo Molnar <>, Vince Weaver <>,
	Paul Mackerras <>,
	Kees Cook <>,
	Arnaldo Carvalho de Melo <>,
	Andrea Arcangeli <>,
	"" <>,
	Valdis Kletnieks <>
Subject: Re: [PATCH v2 7/8] x86, perf: Only allow rdpmc if a perf_event is mapped
Date: Mon, 27 Oct 2014 20:57:36 -0700
Message-ID: <> (raw)
In-Reply-To: <007d01cff260$3c69e9b0$b53dbd10$>

On Mon, Oct 27, 2014 at 8:35 PM, Hillf Danton <> wrote:
>> -----Original Message-----
>> From: Andy Lutomirski []
>> Sent: Monday, October 27, 2014 11:45 PM
>> To: Hillf Danton
>> Cc: Peter Zijlstra; Ingo Molnar; Vince Weaver; Paul Mackerras; Kees Cook; Arnaldo Carvalho de Melo; Andrea Arcangeli; linux-
>>; Valdis Kletnieks
>> Subject: Re: [PATCH v2 7/8] x86, perf: Only allow rdpmc if a perf_event is mapped
> CPU D                   CPU A
> switch_mm
> load_mm_cr4
>                         x86_pmu_event_unmapped
> I wonder if the X86_CR4_PCE set on CPU D is
> cleared by CPU A by broadcasting IPI.

It should be okay.  The IPI does:

+       if (current->mm)
+               load_mm_cr4(current->mm);

which refers to the current task running on the targetted CPU, not to
the IPI sender's task.  So, if it happens after a context switch, it
will harmlessly reload the new task's cr4.

refresh_pce can't happen in between switch_mm and updating current,
since irqs are off for the entire duration of the context switch.


  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-27  7:16 张静(长谷)
2014-10-27 15:45 ` Andy Lutomirski
2014-10-28  3:35   ` Hillf Danton
2014-10-28  3:57     ` Andy Lutomirski [this message]
2014-10-28  4:07       ` Hillf Danton
2014-10-28  4:27         ` Andy Lutomirski
  -- strict thread matches above, loose matches on Subject: below --
2014-10-24 22:58 [PATCH v2 0/8] CR4 handling improvements Andy Lutomirski
2014-10-24 22:58 ` [PATCH v2 7/8] x86, perf: Only allow rdpmc if a perf_event is mapped Andy Lutomirski
2014-10-31 17:54   ` Paolo Bonzini
2014-10-31 18:25     ` Andy Lutomirski

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git
	git clone --mirror lkml/git/9.git
	git clone --mirror lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone