linux-kernel - Re: [RFC PATCH 5/6 v4] perf: Fix race in callchains

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 18 Aug 2010 05:49:46 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Stephane Eranian <eranian@...gle.com>,
	Will Deacon <will.deacon@....com>,
	Paul Mundt <lethal@...ux-sh.org>,
	David Miller <davem@...emloft.net>,
	Borislav Petkov <bp@...64.org>
Subject: Re: [RFC PATCH 5/6 v4] perf: Fix race in callchains

On Tue, Aug 17, 2010 at 02:53:31PM +1000, Paul Mackerras wrote:
> On Tue, Aug 17, 2010 at 03:34:06AM +0200, Frederic Weisbecker wrote:
> 
> > Now that software events don't have interrupt disabled anymore in
> > the event path, callchains can nest on any context. So seperating
> > nmi and others contexts in two buffers has become racy.
> > 
> > Fix this by providing one buffer per nesting level. Given the size
> > of the callchain entries (2040 bytes * 4), we now need to allocate
> > them dynamically.
> > 
> > v2: Fixed put_callchain_entry call after recursion.
> >     Fix the type of the recursion, it must be an array.
> > 
> > v3: Use a manual pr cpu allocation (temporary solution until NMIs
> >     can safely access vmalloc'ed memory).
> 
> It would be nice to make these allocations node-local.


You're right, I'll use kmalloc_node then.

 
> Also, I see that we're allocating 4 buffers per cpu on powerpc when we
> strictly only need 3, but I don't suppose that really matters.


Yeah, we are allocating a similar per-context bunch of buffers for trace
events and also for software events.

If we had a way to know if an arch has nmis, we could manage that.
Whenever this is about simulated or really unmaskable, we don't care,
we just need to know if events can nest on traditional irq disabled
sections.

How do you deal with that in PPC? Is the event delayed to when irqs are
restored?

--
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/