Re: slab: setup allocators earlier in the boot sequence

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2009-06-12 at 13:56 +1000, Benjamin Herrenschmidt wrote:
> > This seem to explode in various places on powerpc :-(
> 
> Main breakage is that slab now gets used a lot earlier than init_IRQ and
> time_init(), but kmalloc() internally hard-enables interrupts when
> GFP_WAIT is passed (it should not but that another side effect of the
> change, see below). So we have the decrementer (CPU timer) popping and
> it crashes on uninitialized data structures in the timer code.
> 
> The reason GFP_WAIT is passed comes from various bits of init code we
> have using a function we call alloc_maybe_bootmem() which does kmalloc
> if initialized and alloc_bootmem() before...

 .../...

And that's not the only problem. The next one is a bit more sneaky, and
I suppose doesn't hit only us...

I'm not sure what's the right fix other than going all the way to having
kmalloc() automagically mask out bits when called at the wrong time.

Typically, what happens here is ioremap() causes __get_vm_area() which
blows up because it does GFP_KERNEL.

Now, that used to work because we have a trick for early ioremap's
(which the arch need, since we do need to ioremap very early, for things
like accessing memory mapped interrupt controllers, or other various low
level platform things).

What we do is VMALLOC_END is defined to be a variable (which we misnamed
ioremap_bot for historical reasons). If ioremap is called before
mem_init() then we allocate virtual space by moving down that variable.
Else, we use get_vm_area().

Now this is broken with the change because after mem_init(), we now use
get_vm_area() which does a kmalloc(...,GFP_KERNEL), which explodes
because it turns on interrupts way too early.

I'll cook up a patch that defines a global bitmask of "forbidden" GFP
bits and see how things go.

Cheers,
Ben.