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

From: Linus Torvalds
Date: Tue Jun 16 2009 - 14:47:42 EST

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.


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

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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at