Re: [PATCH 2/3] perf_events: fix validation of events using an extrareg (v4)

From: Stephane Eranian
Date: Tue Jun 21 2011 - 05:54:31 EST

On Thu, Jun 9, 2011 at 10:48 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> On Thu, 2011-06-09 at 22:36 +0200, Stephane Eranian wrote:
>> On Thu, Jun 9, 2011 at 8:40 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>> > On Mon, 2011-06-06 at 16:57 +0200, Stephane Eranian wrote:
>> >> +static struct cpu_hw_events *allocate_fake_cpuc(void)
>> >> +{
>> >> + Â Â Â struct cpu_hw_events *cpuc;
>> >> + Â Â Â int cpu = smp_processor_id();
>> >
>> > That's a boo-boo, clearly we are in a preemptible context here (see the
>> > GFP_KERNEL allocation on the next line), so using smp_processor_id()
>> > isn't valid.
>> >
>> Good point. I missed that.
> Yeah, I did too, Ingo found it during testing.
>> > Now since all that allocate_shared_regs() does with it is pick a NUMA
>> > node, we should probably use raw_smp_processor_id() and leave it at
>> > that, right?
>> >
Looked at that some more. It is more subtle than this.
allocate_shared_regs() is used in two places:
- allocate_fake_cpuc()
- intel_pmu_cpu_prepare()

In the first case, it does not matter where the cpuc is allocated,
it's not on any
critical path. But for the other situation, it'd better be allocated
on the cpu node.
But I think that is what we get given it is called during the CPU
hotplug prepare
path, so it must be running on the CPU to prepare and thus a kzalloc() should
allocate on the right node, right?

>> Yeah, for what we do with fake_cpuc, it does not really matter where
>> it comes from. This is not on any critical path. The simplest allocator
>> will do it.
> OK, fixed that up.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at