linux-kernel - Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

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]

Message-ID: <alpine.LFD.2.01.0906161141290.3282@localhost.localdomain>
Date:	Tue, 16 Jun 2009 11:45:24 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nick Piggin <npiggin@...e.de>
cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	cl@...ux-foundation.org, kamezawa.hiroyu@...fujitsu.com,
	lizf@...fujitsu.com, mingo@...e.hu, yinghai@...nel.org
Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

On Tue, 16 Jun 2009, Nick Piggin wrote:

> On Tue, Jun 16, 2009 at 07:31:38AM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2009-06-15 at 13:23 +0200, Nick Piggin wrote:
> > > > I think the main problem isn't necessarily init code per se, but the
> > > > pile of -common- code that can be called both at init time and
> > > later.
> > > 
> > > Just seems bogus argument. Everwhere else that does this (ie.
> > > allocations that are called from multiple allocation contexts)
> > > passes correct gfp flags down.
> > 
> > So you say we should create new variants of all these APIs that take gfp
> > flags as arguments just because they might be called early during boot :
> 
> No, just create the ones that actually are called in early boot.

No.

Nick, I don't think you've follow the problems.

The thing is, we do end up wanting to do a lot of allocations, and it's 
not even very "early" - we've already initialized all the allocators. It's 
just that WE HAVE NOT ENABLED INTERRUPTS YET!

So the "hack" is to let everybody act as if everything is normal. Which it 
pretty much is. Just use kmalloc/kfree etc, and use _all_ the regular 
functions. Setting up the core layers so that we _can_ enable interrupts 
involves quite a lot of random crud, they should be able to use regular 
code.

And the hack is there because we really are in a magic stage. The memory 
management works, but it just can't do certain things yet. It's not the 
callers that need to be changed, because the callers are usually regular 
routines that work perfectly normally long after boot, and having to add a 
magic "I'm now doign this during early boot" argument to the whole stack 
is just _stupid_, when the stack itself doesn't actually care - only the 
allocators do.

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