linux-kernel - Re: slab: setup allocators earlier in the boot sequence

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]

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/