Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1603182
| From | tip-bot for Andy Lutomirski <tipbot@zytor.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | [tip:perf/urgent] x86/perf: Clarify why x86_pmu_event_mapped() isn't racy |
| Date | 2017-03-17 11:50 +0100 |
| Message-ID | <tlXCi-535-15@gated-at.bofh.it> (permalink) |
| References | <tlJSG-3pV-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Commit-ID: 4b07372a32c0c1505a7634ad7e607d83340ef645 Gitweb: http://git.kernel.org/tip/4b07372a32c0c1505a7634ad7e607d83340ef645 Author: Andy Lutomirski <luto@kernel.org> AuthorDate: Thu, 16 Mar 2017 12:59:40 -0700 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Fri, 17 Mar 2017 08:28:26 +0100 x86/perf: Clarify why x86_pmu_event_mapped() isn't racy Naively, it looks racy, but ->mmap_sem saves it. Add a comment and a lockdep assertion. Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Borislav Petkov <bpetkov@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/03a1e629063899168dfc4707f3bb6e581e21f5c6.1489694270.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> --- arch/x86/events/core.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index e07b36c..183a972 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -2109,6 +2109,18 @@ static void x86_pmu_event_mapped(struct perf_event *event) if (!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED)) return; + /* + * This function relies on not being called concurrently in two + * tasks in the same mm. Otherwise one task could observe + * perf_rdpmc_allowed > 1 and return all the way back to + * userspace with CR4.PCE clear while another task is still + * doing on_each_cpu_mask() to propagate CR4.PCE. + * + * For now, this can't happen because all callers hold mmap_sem + * for write. If this changes, we'll need a different solution. + */ + lockdep_assert_held_exclusive(¤t->mm->mmap_sem); + if (atomic_inc_return(¤t->mm->context.perf_rdpmc_allowed) == 1) on_each_cpu_mask(mm_cpumask(current->mm), refresh_pce, NULL, 1); }
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH 0/2] x86/perf: A CR4.PCE bugfix and clarification Andy Lutomirski <luto@kernel.org> - 2017-03-16 21:10 +0100
[PATCH 1/2] x86/perf: Fix CR4.PCE propagation to use active_mm instead of mm Andy Lutomirski <luto@kernel.org> - 2017-03-16 21:10 +0100
[tip:perf/urgent] x86/perf: Fix CR4.PCE propagation to use active_mm instead of mm tip-bot for Andy Lutomirski <tipbot@zytor.com> - 2017-03-17 11:50 +0100
[PATCH 2/2] x86/perf: Clarify why x86_pmu_event_mapped() isn't racy Andy Lutomirski <luto@kernel.org> - 2017-03-16 21:10 +0100
[tip:perf/urgent] x86/perf: Clarify why x86_pmu_event_mapped() isn't racy tip-bot for Andy Lutomirski <tipbot@zytor.com> - 2017-03-17 11:50 +0100
csiph-web