[PATCH] Ensure that kernel_init_freebale() is not inlined into non __init code

From: Vineet.Gupta1
Date: Fri Nov 16 2012 - 08:34:47 EST


From: Vineet Gupta <vgupta@xxxxxxxxxxxx>

Commit d6b2123802d "make sure that we always have a return path from
kernel_execve()" reshuffled kernel_init()/init_post() to ensure that
kernel_execve() has a caller to return to.
Just for documentation, here's what that commit did.

Orig
----

THREAD __init kernel_init()
smp_init()
...
open("/dev/console")

init_post() --> forced to be noinline
return 0;

init_post()
free_initmem() --> reaps caller kernel_init()
run_init_process("/init")
kernel_execve

New
---

THREAD kernel_init()
kernel_init_freeable() --> __init tagged
smp_init()
...
open("/dev/console")
free_initmem() --> reaps kernel_init_freeable()
run_init_process "init"
kernel_execve

However kernel_init_freebale() was NOT marked as noinline making ARC gcc
4.4 inline it in non __init freeable kernel_init(), wasting a bit of
memory.

bloat-o-meter vmlinux_orig vmlinux
add/remove: 1/0 grow/shrink: 0/1 up/down: 374/-330 (44)
function old new delta
kernel_init_freeable - 374 +374
kernel_init 636 306 -330

Signed-off-by: Vineet Gupta <vgupta@xxxxxxxxxxxx>
---
init/main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/init/main.c b/init/main.c
index e33e09d..cd147a9 100644
--- a/init/main.c
+++ b/init/main.c
@@ -800,7 +800,7 @@ static int run_init_process(const char *init_filename)
return kernel_execve(init_filename, argv_init, envp_init);
}

-static void __init kernel_init_freeable(void);
+static noinline void __init kernel_init_freeable(void);

static int __ref kernel_init(void *unused)
{
@@ -844,7 +844,7 @@ static int __ref kernel_init(void *unused)
"See Linux Documentation/init.txt for guidance.");
}

-static void __init kernel_init_freeable(void)
+static noinline void __init kernel_init_freeable(void)
{
/*
* Wait until kthreadd is all set-up.
--
1.7.4.1

--
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/