From: Frank Rowand <frowand.list@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Chuck Ebbert <cebbert.lkml@gmail.com>,
Rob Landley <rob@landley.net>,
Randy Dunlap <rdunlap@infradead.org>,
Shuah Khan <shuah.kh@samsung.com>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH v5] init: Disable defaults if init= fails
Date: Tue, 30 Sep 2014 17:41:07 -0700 [thread overview]
Message-ID: <542B4DA3.5080105@gmail.com> (raw)
In-Reply-To: <5c6381879bea68aebb13530442f1cf8a052be97f.1411958379.git.luto@amacapital.net>
The earliest mention I find of this on lkml is v4. Was there earlier
discussion of this elsewhere? (Just so I have a clue as to the full
context and don't repeat previous discussion.) The mention of names
in the change logs tells me I should be able to find the discussion
somewhere.
On 9/28/2014 7:40 PM, Andy Lutomirski wrote:
> 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 makes a failure to run the specified init= process be fatal.
>
> As a temporary measure, users can set CONFIG_INIT_FALLBACK=y to
> preserve the old behavior. If no one speaks up, we can remove that
> option entirely after a release or two.
I'm speaking up already, no need to wait two releases. I like the
current behavior where I can fall back into a shell without
recompiling the kernel and/or changing the boot command line to
debug an init failure.
I would suggest that the current behavior remain the
default and the choice to make a failure of the specified
init= process fatal should be an explicit choice.
Instead of using a config option, would adding another kernel
command line option, such as 'init_fail_is_fatal', work for
your needs? I have a feeling this has already been proposed,
as the 'strictinit' option mentioned in the changes from v3
below might be the same concept?
Thanks,
Frank
>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>
> Changes from v4:
> - Update the panic message (sorry for the noise)
>
> Changes from v3:
> - Get rid of the strictinit option. Now the new behavior is the default
> unless CONFIG_INIT_FALLBACK=y (Rob Landley)
>
> Changes from v2:
> - Improve docs further, to leave the door open to giving strictinit
> some sensible semantics if init= is not set.
> - Improve error output in the failure case (Shuah Khan).
>
> Changes from v1:
> - Add missing "if" to the docs (Randy Dunlap)
>
> init/Kconfig | 11 +++++++++++
> init/main.c | 7 ++++++-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index e84c6423a2e5..063029a1556f 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1299,6 +1299,17 @@ source "usr/Kconfig"
>
> endif
>
> +config INIT_FALLBACK
> + bool "Fall back to defaults if init= parameter is bad"
> + help
> + If enabled, the kernel will try the default init binaries if an
> + explicit request from the init= parameter fails.
> +
> + This is a temporary measure to allow broken configurations
> + to continue to boot.
> +
> + If unsure, say N.
> +
> config CC_OPTIMIZE_FOR_SIZE
> bool "Optimize for size"
> help
> diff --git a/init/main.c b/init/main.c
> index bb1aed928f21..2bd6105e5dc5 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -960,8 +960,13 @@ static int __ref kernel_init(void *unused)
> 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") ||
>
next prev parent reply other threads:[~2014-10-01 0:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-29 2:40 [PATCH v5] init: Disable defaults if init= fails Andy Lutomirski
2014-09-30 12:12 ` Chuck Ebbert
2014-10-01 0:41 ` Frank Rowand [this message]
2014-10-01 0:58 ` Rob Landley
2014-10-01 1:52 ` Frank Rowand
2014-10-01 3:16 ` Rob Landley
2014-10-01 4:53 ` Andy Lutomirski
2014-10-01 18:05 ` josh
2014-10-01 18:13 ` Andy Lutomirski
2014-10-01 22:42 ` josh
2014-10-14 21:00 ` Andrew Morton
2014-10-14 21:21 ` Andy Lutomirski
2014-10-15 5:46 ` Frank Rowand
2014-10-15 5:56 ` Andy Lutomirski
2014-10-15 6:37 ` Frank Rowand
2014-10-15 15:18 ` Rob Landley
2014-10-20 20:14 ` Andy Lutomirski
2014-10-20 21:01 ` Josh Triplett
2014-10-20 21:28 ` Andrew Morton
2014-10-20 21:34 ` Andy Lutomirski
2014-10-20 21:41 ` Andrew Morton
2014-10-20 21:42 ` Andy Lutomirski
2014-10-20 21:44 ` Andrew Morton
2014-10-20 22:04 ` [PATCH] init: Remove CONFIG_INIT_FALLBACK Andy Lutomirski
2014-10-20 22:06 ` josh
2014-10-21 3:45 ` Rob Landley
2014-10-21 4:02 ` Andy Lutomirski
2014-10-21 4:15 ` Rob Landley
2014-10-21 9:53 ` Geert Uytterhoeven
2014-10-21 10:05 ` Josh Triplett
2014-10-14 0:47 ` [PATCH v5] init: Disable defaults if init= fails Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=542B4DA3.5080105@gmail.com \
--to=frowand.list@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cebbert.lkml@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=rdunlap@infradead.org \
--cc=rob@landley.net \
--cc=rusty@rustcorp.com.au \
--cc=shuah.kh@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.