Messages in this thread | | | Date | Tue, 21 Jun 2011 11:54:21 +0200 | Subject | Re: [PATCH 2/3] perf_events: fix validation of events using an extra reg (v4) | From | Stephane Eranian <> |
| |
On Thu, Jun 9, 2011 at 10:48 PM, Peter Zijlstra <peterz@infradead.org> 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@infradead.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |