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 kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
