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

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: <1245192673.14036.44.camel@pasglop>
Date:	Wed, 17 Jun 2009 08:51:13 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	kamezawa.hiroyu@...fujitsu.com, lizf@...fujitsu.com, mingo@...e.hu,
	yinghai@...nel.org
Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

On Tue, 2009-06-16 at 15:06 -0700, Linus Torvalds wrote:
> Why do you need ioremap so early that it has to happen before even the 
> basic MM data is up? That sounds bogus, and like just a random 
> implementation issue for historical reasons.

ioremap is probably the -one- thing we constantly try to move
earlier ... sadly :-) But again, I agree and it's mostly historical
reason, coupled with the lack of good "generic" (rather than dedicated
like mem_init(), time_init(), init_IRQ() ...) archs hooks after
setup_arch() and before full blown initcalls.

The main user of it is debugging. We have debug options that can
initialize some kind of console output pretty much even before
setup_arch() is called :-) Most of that stuff isn't normally compiled in
a production kernel though.

Now, if we could do less things in setup_arch() we would have less need
to debug stuff in there, that's true :-) The worst offender is probably
ppc64 which currently does shitloads of stuff even before we call
start_kernel() and that is just plain wrong.

This stuff has been on my to-fix list for a long time, I want to move a
lot of it to later during the boot process and make it more common
between 32 and 64 bit etc... Just give me some time :-)

A few other users of that sort of early ioremap are some bits that
access chipset registers to fixup crap, most of it is in setup_arch()
because we don't actually have a good arch callback that comes later and
is still reasonably before anything important takes place. Maybe we
should introduce one just after the initialization of the allocators.

On ppc32, we also ioremap IO space from setup_arch() and on ppc64 we do
that but only for the legacy part of it. That also could be moved as we
move the PHB init later.

Oh, one big one too is access to the system controller registers (aka
Cuda or PMU on powermacs) which we also do very early.

None of that is unfixable, and in some case even hard to fix. But just
don't remove slab_is_available() -just-yet- :-)

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/