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]

Date:	Tue, 16 Jun 2009 12:33:58 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Christoph Lameter <cl@...ux-foundation.org>
cc:	Benjamin Herrenschmidt <benh@...nel.crashing.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, 16 Jun 2009, Christoph Lameter wrote:
> >
> > I'd rather get rid of the whole slab_is_available() thing entirely.
> 
> slab_is_available is necessary for slab bootstrap but if we use
> system_state for this then its not necessary anymore.

Well, if it's purely internal to slab itself, then I don't care. It should 
be made static inside mm/slab.c

> > IOW, we should strive for not having any code that is at all confused
> > about whether it can do slab allocations or not.
> 
> So encode the stage of boot up in system_state? Maybe add documentation to
> explan what is possible at these states and what is not?

No.

I mean that there should never be any _need_ for dynamically querying 
whether slab is available or not. Nothing should ever do it, because we 
should strive for slab being available so early that anything that happens 
before it _knows_ that it is special case code (eg "set up initial page 
tables") and would never have any reason what-so-ever for even 
conditionally asking "should I use slab".

So I literally mean "get rid of slab_is_available()" - and the fact that 
SLAB itself _internally_ has some internal state is irrelevant (SLUB and 
SLOB do not, for example).

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