linux-kernel - Re: irq lock inversion

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]

Message-ID: <4AF45109.7070503@kernel.org>
Date:	Sat, 07 Nov 2009 01:38:33 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	Ingo Molnar <mingo@...e.hu>, Nick Piggin <npiggin@...e.de>,
	Jiri Kosina <jkosina@...e.cz>,
	Peter Zijlstra <peterz@...radead.org>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: irq lock inversion

Christoph Lameter wrote:
> On Fri, 6 Nov 2009, Tejun Heo wrote:
> 
>> Ingo Molnar wrote:
>>> My question is, why do we do flags save/restore in pcpu-alloc?
>> That's strictly for calls from sched_init().
> 
> Right its a hack for 2.6.32. Fix it the right way by making the per cpu
> allocator take gfp flags like any other allocator in the kernel.

vmalloc/vfree is an allocator in the kernel and can't be called from
irq context and doesn't take gfp flags.  percpu allocator being
dependent on vmalloc area, it's gonna be a bit tricky.  It's
definitely doable but I'm still not quite sure whether the benfit
would worth the added complexity.  The only known use case is for lazy
allocation from memory allocator, right?  How much does it hurt not to
have that lazy allocation?

Thanks.

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