Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757488AbZFPTMR (ORCPT ); Tue, 16 Jun 2009 15:12:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751995AbZFPTMF (ORCPT ); Tue, 16 Jun 2009 15:12:05 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:47637 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751043AbZFPTME (ORCPT ); Tue, 16 Jun 2009 15:12:04 -0400 Date: Tue, 16 Jun 2009 12:10:15 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Christoph Lameter cc: Benjamin Herrenschmidt , Nick Piggin , Pekka Enberg , Heiko Carstens , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, kamezawa.hiroyu@jp.fujitsu.com, lizf@cn.fujitsu.com, mingo@elte.hu, yinghai@kernel.org Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31 In-Reply-To: Message-ID: References: <20090615081831.GA5411@osiris.boeblingen.de.ibm.com> <84144f020906150210w7fa29042xc12efb4a087e3d26@mail.gmail.com> <20090615094148.GC1314@wotan.suse.de> <1245059476.12400.7.camel@pasglop> <20090615101254.GB10294@wotan.suse.de> <1245062388.12400.17.camel@pasglop> <20090615112205.GA6012@wotan.suse.de> <20090615112827.GC6012@wotan.suse.de> <1245101567.12400.38.camel@pasglop> User-Agent: Alpine 2.01 (LFD 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1621 Lines: 40 On Tue, 16 Jun 2009, Christoph Lameter wrote: > On Tue, 16 Jun 2009, Benjamin Herrenschmidt wrote: > > > On Mon, 2009-06-15 at 13:28 +0200, Nick Piggin wrote: > > > If a couple of specialised early boot code places have > > > to test slab_is_available() to prevent crap leaking into > > > our main allocators, then that's quite fine by me. > > > > slab_is_available() will not fix the problem in that case. In fact, > > existing tests of slab_is_available() have been broken because they > > assumed that when it was true, then GFP_KERNEL would work. > > Can we get rid of slab_is_available for that purpose? AFAICT: There needs > to be something that tells us that the page allocator is available or that > the mm subsystem is fully operational. > > Could we add more bootup states to enum system_states? I'd rather get rid of the whole slab_is_available() thing entirely. All the recent init ordering changes should mean that the slab allocator is available _much_ earlier - to the point that hopefully any code that runs before slab is initialized should know very deep down that it's special, and uses the bootmem allocator without doing any conditionals what-so-ever. If that isn't true yet, then we should make it more true. IOW, we should strive for not having any code that is at all confused about whether it can do slab allocations or not. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/