Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755890AbYHYSKK (ORCPT ); Mon, 25 Aug 2008 14:10:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753868AbYHYSJ6 (ORCPT ); Mon, 25 Aug 2008 14:09:58 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:56419 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753562AbYHYSJ5 (ORCPT ); Mon, 25 Aug 2008 14:09:57 -0400 Date: Mon, 25 Aug 2008 11:09:36 -0700 (PDT) From: Linus Torvalds To: "Alan D. Brunelle" cc: "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Andrew Morton , Arjan van de Ven , Rusty Russell Subject: Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected In-Reply-To: Message-ID: References: <48B29F7B.6080405@hp.com> <48B2A421.7080705@hp.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) 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: 2354 Lines: 57 On Mon, 25 Aug 2008, Linus Torvalds wrote: > > Could you make your kernel image available somewhere, and we can take a > look at it? Some versions of gcc are total pigs when it comes to stack > usage, and your exact configuration matters too. But yes, module loading > is a bad case, for me "sys_init_module()" contains > > subq $392, %rsp #, > > which is probably mostly because of the insane inlining gcc does (ie it > will likely have inlined every single function in that file that is only > called once, and then it will make all local variables of all those > functions alive over the whole function and allocate stack-space for them > ALL AT THE SAME TIME). I bet this one-liner will probably make your kernel work. It's not a full solution, but it will make the module-loading path lose _all_ of the above stack slots by just not inlining "load_module()" - the stack slots will still be used when the module is _loaded_, but by the time we actually callt he ->init function they will have been released since it's not all in the same crazy function any more. I _seriously_ believe that we were better off back when gcc only inlined what we told it to inline, and never inlined on its own. The gcc inlining logic is pure and utter sh*t in an environment like the kernel where stack space is a valuable resource. Anyway, Alan, even if this solves your particular problem, I'd still like to see your kernel image, so that I can hunt for other problems like this.. Linus --- kernel/module.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index 08864d2..9db1191 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -1799,7 +1799,7 @@ static void *module_alloc_update_bounds(unsigned long size) /* Allocate and load the module: note that size of section 0 is always zero, and we rely on this for optional sections. */ -static struct module *load_module(void __user *umod, +static noinline struct module *load_module(void __user *umod, unsigned long len, const char __user *uargs) { -- 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/