Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 27 Oct 2014 21:27:56 -0700 | Subject | Re: [PATCH v2 7/8] x86, perf: Only allow rdpmc if a perf_event is mapped |
| |
On Mon, Oct 27, 2014 at 9:07 PM, Hillf Danton <hillf.zj@alibaba-inc.com> wrote: >> >> 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. >> > Right, but prev != next is checked in switch_mm.
If that happens and !cpumask_test_cpu(cpu, mm_cpumask(next)), then cr4 will be reloaded. So, in the case you described, we should still be okay.
It's worth checking whether a more complicated race could be a problem. I think it's okay. Here's my argument.
In x86_pmu_event_mapped / x86_pmu_event_unmapped, for each cpu, either that cpu is set in mm_cpumask or it's clear. If it's set, then we'll send the IPI and that cpu is guaranteed to be updated. If it's clear, then it must become set before any user code in this mm can be executed. There are no paths through switch_mm that set the bit in mm_cpumask without reloading cr4, so we should be safe.
Is that convincing?
--Andy
> > Hillf > >
-- Andy Lutomirski AMA Capital Management, LLC
| |