linux-kernel - Re: [PATCH 2/3] perf_events: fix validation of events using an extra reg (v4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jun 2011 11:54:21 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
	Lin Ming <ming.m.lin@...el.com>
Subject: Re: [PATCH 2/3] perf_events: fix validation of events using an extra
 reg (v4)

On Thu, Jun 9, 2011 at 10:48 PM, Peter Zijlstra <peterz@...radead.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@...radead.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/