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

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

The problem is that we routinely call that with GFP_KERNEL since we used
to know it would default to bootmem before IRQs can be enabled safely,
which is no longer the case.

At this stage, I'm tempted to rip the all off and just use kmalloc
GFP_NOWAIT for now.

But it would be useful to have kmalloc -itself- remove GFP_WAIT when
called to early so that code doesn't have to do something different
depending on when it's called. In fact, we similarily need to remove
__GFP_IO/FS when in suspend/resume sequence...

For example, we have code for allocating IRQ remapping related data
structures that can be called very early at init_IRQ() time, or later if
some driver or bus wants to register a cascaded IRQ controller.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ