Re: [PATCH 2/3] early_printk: Add force_early_printk kernel parameter

[Petr Mladek]

On Thu 2017-09-28 14:18:25, Peter Zijlstra wrote:
> Add add the 'force_early_printk' kernel parameter to override printk()
> and force it into early_printk(). This bypasses all the cruft and fail
> from printk() and makes things work again.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> ---
>  kernel/printk/printk.c |   68 +++++++++++++++++++++++++++++++++----------------
>  1 file changed, 47 insertions(+), 21 deletions(-)
> 
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -365,6 +365,42 @@ __packed __aligned(4)
>  #endif
>  ;
>  
> +#ifdef CONFIG_EARLY_PRINTK
> +struct console *early_console;
> +
> +static bool __read_mostly force_early_printk;
> +
> +static int __init force_early_printk_setup(char *str)
> +{
> +	force_early_printk = true;
> +	return 0;
> +}
> +early_param("force_early_printk", force_early_printk_setup);

The parameter is currently used only when CONFIG_PRINTK is enabled.
But CONFIG_EARLY_PRINTK is independent. What would be your preferred
behavior when CONFIG_PRINTK is disabled, please?


> @@ -1816,6 +1852,11 @@ asmlinkage int vprintk_emit(int facility
>  		return vkdb_printf(KDB_MSGSRC_PRINTK, fmt, args);
>  #endif
>  
> +#ifdef CONFIG_EARLY_PRINTK
> +	if (force_early_printk && early_console)
> +		return early_vprintk(fmt, args);
> +#endif
> +
>  	if (level == LOGLEVEL_SCHED) {
>  		level = LOGLEVEL_DEFAULT;
>  		in_sched = true;
> @@ -1939,7 +1980,12 @@ asmlinkage __visible int printk(const ch
>  	int r;
>  
>  	va_start(args, fmt);
> -	r = vprintk_func(fmt, args);
> +#ifdef CONFIG_EARLY_PRINTK
> +	if (force_early_printk && early_console)
> +		r = vprintk_default(fmt, args);
> +	else
> +#endif
> +		r = vprintk_func(fmt, args);

There is rather theoretical race. We skip vprintk_func() because
we believe that vprintk_default()/vprintk_emit() would choose
handle this by early_printk().

A solution would be the clean up of the exported printk() interfaces
that I suggested in the other mail. Then we could choose the right
implementation on a single place: printk_func().

PeterZ, I guess that you do not want to spend much time on this.
But if you basically agree with my proposal, I could start
working on it and rebase this patchset on top of it.

Best Regards,
Petr

PS: I am sorry that I am complicating this rather simple patchset.
I only want to be careful. You know that the current printk code
is a mess and I would like to improve it.