The patch titled
Subject: init: allow CONFIG_INIT_FALLBACK=n to disable defaults if init= fails
has been added to the -mm tree. Its filename is
init-allow-config_init_fallback=n-to-disable-defaults-if-init=-fails.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/init-allow-config_init_fallback=n-to-disable-defaults-if-init=-fails.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/init-allow-config_init_fallback=n-to-disable-defaults-if-init=-fails.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
Subject: init: allow CONFIG_INIT_FALLBACK=n to disable defaults if init= fails
If a user puts init=/whatever on the command line and /whatever can't be
run, then the kernel will try a few default options before giving up. If
init=/whatever came from a bootloader prompt, then this is unexpected but
probably harmless. On the other hand, if it comes from a script (e.g. a
tool like virtme or perhaps a future kselftest script), then the fallbacks
are likely to exist, but they'll do the wrong thing. For example, they
might unexpectedly invoke systemd.
This adds a config option CONFIG_INIT_FALLBACK. If unset, then a failure
to run the specified init= process be fatal.
The intent is to switch the default to N after a while and to possibly
even remove the option entirely
Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
Cc: Rob Landley <rob@xxxxxxxxxxx>
Cc: Chuck Ebbert <cebbert.lkml@xxxxxxxxx>
Cc: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
Cc: Shuah Khan <shuah.kh@xxxxxxxxxxx>
Cc: Frank Rowand <frowand.list@xxxxxxxxx>
Cc: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
Cc: Acked-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
init/Kconfig | 16 ++++++++++++++++
init/main.c | 7 ++++++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff -puN init/Kconfig~init-allow-config_init_fallback=n-to-disable-defaults-if-init=-fails init/Kconfig
--- a/init/Kconfig~init-allow-config_init_fallback=n-to-disable-defaults-if-init=-fails
+++ a/init/Kconfig
@@ -1299,6 +1299,22 @@ source "usr/Kconfig"
endif
+config INIT_FALLBACK
+ bool "Fall back to defaults if init= parameter is bad"
+ default y
+ help
+ If enabled, the kernel will try the default init binaries if an
+ explicit request from the init= parameter fails.
+
+ This can have unexpected effects. For example, booting
+ with init=/sbin/kiosk_app will run /sbin/init or even /bin/sh
+ if /sbin/kiosk_app cannot be executed.
+
+ The default value of Y is consistent with historical behavior.
+ Selecting N is likely to be more appropriate for most uses,
+ especially on kiosks and on kernels that are indended to be
+ run under the control of a script.
+
config CC_OPTIMIZE_FOR_SIZE
bool "Optimize for size"
help
diff -puN init/main.c~init-allow-config_init_fallback=n-to-disable-defaults-if-init=-fails init/main.c
--- a/init/main.c~init-allow-config_init_fallback=n-to-disable-defaults-if-init=-fails
+++ a/init/main.c
@@ -959,8 +959,13 @@ static int __ref kernel_init(void *unuse
ret = run_init_process(execute_command);
if (!ret)
return 0;
+#ifndef CONFIG_INIT_FALLBACK
+ panic("Requested init %s failed (error %d).",
+ execute_command, ret);
+#else
pr_err("Failed to execute %s (error %d). Attempting defaults...\n",
- execute_command, ret);
+ execute_command, ret);
+#endif
}
if (!try_to_run_init_process("/sbin/init") ||
!try_to_run_init_process("/etc/init") ||
_
Patches currently in -mm which might be from luto@xxxxxxxxxxxxxx are
init-allow-config_init_fallback=n-to-disable-defaults-if-init=-fails.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
