Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

Alan D. Brunelle
2008-08-25T20:19:44Z

Linus Torvalds wrote:
>
> 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).

Mine has:

Dump of assembler code for function sys_init_module:
0xffffffff802688c0 <sys_init_module+0>: push %rbp
0xffffffff802688c1 <sys_init_module+1>: mov %rsp,%rbp
0xffffffff802688c4 <sys_init_module+4>: sub $0x1c0,%rsp
0xffffffff802688cb <sys_init_module+11>: mov %r12,-0x20(%rbp)
0xffffffff802688cf <sys_init_module+15>: mov %rdi,%r12

so 448 bytes.

The kernel is up at: http://free.linux.hp.com/~adb/bug.11342/vmlinux (if
you would let me know when you are through with it so I can free up some
space there I'd appreciate it...)

By doing the patch you provided, sys_init_module now looks like:

Dump of assembler code for function sys_init_module:
0xffffffff8026aa20 <sys_init_module+0>: push %rbp
0xffffffff8026aa21 <sys_init_module+1>: mov %rsp,%rbp
0xffffffff8026aa24 <sys_init_module+4>: sub $0x20,%rsp
0xffffffff8026aa28 <sys_init_module+8>: mov %r14,0x18(%rsp)
0xffffffff8026aa2d <sys_init_module+13>: mov %rdi,%r14

So only 32 bytes. (But of course, load_module() exists, and now has
0x1d0 (464) bytes...)

With the patch you provide, I /was/ able to repeatedly boot OK (latest
tree, and I also ran the patch against the 26.27.rc3-based kernel I was
having problems with initially, and that booted OK as well).

Alan

>
> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/