From 808bf29b9195c52239b9aaeda7c6082a0ddf07c6 Mon Sep 17 00:00:00 2001 From: Alexander Sverdlin Date: Wed, 21 Sep 2011 09:51:40 +0200 Subject: init: carefully handle loglevel option on kernel cmdline. When a malformed loglevel value (for example "${abc}") is passed on the kernel cmdline, the loglevel itself is being set to 0. That then suppresses all following messages, including all the errors and crashes caused by other malformed cmdline options. This could make debugging process quite tricky. This patch leaves the previous value of loglevel if the new value is incorrect and reports an error code in this case. Signed-off-by: Alexander Sverdlin Signed-off-by: Linus Torvalds --- init/main.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) (limited to 'init') diff --git a/init/main.c b/init/main.c index 9c51ee7adf3..2a9b88aa5e7 100644 --- a/init/main.c +++ b/init/main.c @@ -209,8 +209,19 @@ early_param("quiet", quiet_kernel); static int __init loglevel(char *str) { - get_option(&str, &console_loglevel); - return 0; + int newlevel; + + /* + * Only update loglevel value when a correct setting was passed, + * to prevent blind crashes (when loglevel being set to 0) that + * are quite hard to debug + */ + if (get_option(&str, &newlevel)) { + console_loglevel = newlevel; + return 0; + } + + return -EINVAL; } early_param("loglevel", loglevel); -- cgit v1.2.3 From d5767c53535ac79758084773418e0ad186aba4a2 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Wed, 28 Sep 2011 10:23:44 -0700 Subject: bootup: move 'usermodehelper_enable()' to the end of do_basic_setup() Doing it just before starting to call into cpu_idle() made a sick kind of sense only because the original bug we fixed (see commit 288d5abec831: "Boot up with usermodehelper disabled") was about problems with some scheduler data structures not being initialized, and they had better be initialized at that point. But it really didn't make any other conceptual sense, and doing it after the initial "schedule()" call for the idle thread actually opened up a race: what if the main initialization thread did everything without needing to sleep, and got all the way into user land too? Without actually having scheduled back to the idle thread? Now, in normal circumstances that doesn't ever happen, but it looks like Richard Cochran triggered exactly that on his ARM IXP4xx machines: "I have some ARM IXP4xx based machines that use the two on chip MAC ports (aka NPEs). The NPE needs a firmware in order to function. Ever since the following commit [that 288d5abec831 one], it is no longer possible to bring up the interfaces during the init scripts." with a call trace showing an ioctl coming from user space. Richard says: "The init is busybox, and the startup script does mount, syslogd, and then ifup, so that all can go by quickly." The fix is to move the usermodehelper_enable() into the main 'init' thread, and just put it after we've done all our initcalls. By then, everything really should be up, but we've obviously not actually started the user-mode portion of init yet. Reported-and-tested-by: Richard Cochran Signed-off-by: Linus Torvalds --- init/main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'init') diff --git a/init/main.c b/init/main.c index 2a9b88aa5e7..23702bbdbc1 100644 --- a/init/main.c +++ b/init/main.c @@ -381,9 +381,6 @@ static noinline void __init_refok rest_init(void) preempt_enable_no_resched(); schedule(); - /* At this point, we can enable user mode helper functionality */ - usermodehelper_enable(); - /* Call into cpu_idle with preempt disabled */ preempt_disable(); cpu_idle(); @@ -734,6 +731,7 @@ static void __init do_basic_setup(void) init_irq_proc(); do_ctors(); do_initcalls(); + usermodehelper_enable(); } static void __init do_pre_smp_initcalls(void) -- cgit v1.2.3 From b0f84374b6ab0dc9c47975df0b02d46165d558d4 Mon Sep 17 00:00:00 2001 From: wangyanqing Date: Thu, 29 Sep 2011 15:09:40 +0800 Subject: bootup: move 'usermodehelper_enable()' a little earlier Commit d5767c53535a ("bootup: move 'usermodehelper_enable()' to the end of do_basic_setup()") moved 'usermodehelper_enable()' to end of do_basic_setup() to after the initcalls. But then I get failed to let uvesafb work on my computer, and lose the splash boot. So maybe we could start usermodehelper_enable a little early to make some task work that need eary init with the help of user mode. [ I would *really* prefer that initcalls not call into user space - even the real 'init' hasn't been execve'd yet, after all! But for uvesafb it really does look like we don't have much choice. I considered doing this when we mount the root filesystem, but depending on config options that is in multiple places. We could do the usermode helper enable as a rootfs_initcall().. So I'm just using wang yanqing's trivial patch. It's not wonderful, but it's simple and should work. We should revisit this some day, though. - Linus ] Signed-off-by: Linus Torvalds --- init/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'init') diff --git a/init/main.c b/init/main.c index 23702bbdbc1..03b408dff82 100644 --- a/init/main.c +++ b/init/main.c @@ -730,8 +730,8 @@ static void __init do_basic_setup(void) driver_init(); init_irq_proc(); do_ctors(); - do_initcalls(); usermodehelper_enable(); + do_initcalls(); } static void __init do_pre_smp_initcalls(void) -- cgit v1.2.3