2021-10-13 22:36:35

by Andrew Halaney

[permalink] [raw]
Subject: [PATCH] init: Make unknown command line param message clearer

The prior message is confusing users, which is the exact opposite of the
goal. If the message is being seen, one of the following situations is
happening:

1. the param is misspelled
2. the param is not valid due to the kernel configuration
3. the param is intended for init but isn't after the '--'
delineator on the command line

To make that more clear to the user, explicitly mention "kernel command
line" and also note that the params are still passed to user space to
avoid causing any alarm over params intended for init.

Fixes: 86d1919a4fb0 ("init: print out unknown kernel parameters")
Suggested-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Andrew Halaney <[email protected]>
---

Here's v2 of this. I had to change the code a bit from what Steven
recommended to compile/look proper, but the intended format he had
suggested is still the same.

v1 -> v2:
* Print a much more concise message

v1: https://lore.kernel.org/all/[email protected]/

Thanks,
Andrew

init/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/init/main.c b/init/main.c
index ee4d3e1b3eb9..a286995449e2 100644
--- a/init/main.c
+++ b/init/main.c
@@ -925,7 +925,9 @@ static void __init print_unknown_bootoptions(void)
for (p = &envp_init[2]; *p; p++)
end += sprintf(end, " %s", *p);

- pr_notice("Unknown command line parameters:%s\n", unknown_options);
+ /* Start at unknown_options[1] to skip the initial space */
+ pr_notice("Unknown kernel command line parameters \"%s\", will be passed to user space.\n",
+ &unknown_options[1]);
memblock_free(unknown_options, len);
}

--
2.31.1


2021-10-13 22:51:02

by Randy Dunlap

[permalink] [raw]
Subject: Re: [PATCH] init: Make unknown command line param message clearer

On 10/13/21 3:35 PM, Andrew Halaney wrote:
> The prior message is confusing users, which is the exact opposite of the
> goal. If the message is being seen, one of the following situations is
> happening:
>
> 1. the param is misspelled
> 2. the param is not valid due to the kernel configuration
> 3. the param is intended for init but isn't after the '--'
> delineator on the command line
>
> To make that more clear to the user, explicitly mention "kernel command
> line" and also note that the params are still passed to user space to
> avoid causing any alarm over params intended for init.
>
> Fixes: 86d1919a4fb0 ("init: print out unknown kernel parameters")
> Suggested-by: Steven Rostedt (VMware) <[email protected]>
> Signed-off-by: Andrew Halaney <[email protected]>
> ---
>
> Here's v2 of this. I had to change the code a bit from what Steven
> recommended to compile/look proper, but the intended format he had
> suggested is still the same.
>
> v1 -> v2:
> * Print a much more concise message
>
> v1: https://lore.kernel.org/all/[email protected]/
>
> Thanks,
> Andrew
>
> init/main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/init/main.c b/init/main.c
> index ee4d3e1b3eb9..a286995449e2 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -925,7 +925,9 @@ static void __init print_unknown_bootoptions(void)
> for (p = &envp_init[2]; *p; p++)
> end += sprintf(end, " %s", *p);
>
> - pr_notice("Unknown command line parameters:%s\n", unknown_options);
> + /* Start at unknown_options[1] to skip the initial space */
> + pr_notice("Unknown kernel command line parameters \"%s\", will be passed to user space.\n",
> + &unknown_options[1]);
> memblock_free(unknown_options, len);
> }
>
>

LGTM. Thanks.

Acked-by: Randy Dunlap <[email protected]>

--
~Randy

2021-10-13 23:16:00

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH] init: Make unknown command line param message clearer

On Wed, 13 Oct 2021 17:35:02 -0500 Andrew Halaney <[email protected]> wrote:

> The prior message is confusing users, which is the exact opposite of the
> goal. If the message is being seen, one of the following situations is
> happening:
>
> 1. the param is misspelled
> 2. the param is not valid due to the kernel configuration
> 3. the param is intended for init but isn't after the '--'
> delineator on the command line
>
> To make that more clear to the user, explicitly mention "kernel command
> line" and also note that the params are still passed to user space to
> avoid causing any alarm over params intended for init.
>
> Fixes: 86d1919a4fb0 ("init: print out unknown kernel parameters")
> Suggested-by: Steven Rostedt (VMware) <[email protected]>
> Signed-off-by: Andrew Halaney <[email protected]>

Thanks.

BTW, I'm still sitting on your "init/main.c: silence some
-Wunused-parameter warnings", awaiting a response to Rasmus's
suggestion:
https://lkml.kernel.org/r/[email protected]

2021-10-14 14:27:17

by Andrew Halaney

[permalink] [raw]
Subject: Re: [PATCH] init: Make unknown command line param message clearer

On Wed, Oct 13, 2021 at 04:12:59PM -0700, Andrew Morton wrote:
> On Wed, 13 Oct 2021 17:35:02 -0500 Andrew Halaney <[email protected]> wrote:
>
> > The prior message is confusing users, which is the exact opposite of the
> > goal. If the message is being seen, one of the following situations is
> > happening:
> >
> > 1. the param is misspelled
> > 2. the param is not valid due to the kernel configuration
> > 3. the param is intended for init but isn't after the '--'
> > delineator on the command line
> >
> > To make that more clear to the user, explicitly mention "kernel command
> > line" and also note that the params are still passed to user space to
> > avoid causing any alarm over params intended for init.
> >
> > Fixes: 86d1919a4fb0 ("init: print out unknown kernel parameters")
> > Suggested-by: Steven Rostedt (VMware) <[email protected]>
> > Signed-off-by: Andrew Halaney <[email protected]>
>
> Thanks.
>
> BTW, I'm still sitting on your "init/main.c: silence some
> -Wunused-parameter warnings", awaiting a response to Rasmus's
> suggestion:
> https://lkml.kernel.org/r/[email protected]
>

Whoops, that got caught in spam (along with rostedt's replies
yesterday... darn gmail). Let me add looking at that to the todo list,
thanks Andrew!