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  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:	Fri, 12 Jun 2009 14:25:56 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: slab: setup allocators earlier in the boot sequence

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.


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

Powered by blists - more mailing lists