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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
