Messages in this thread | | | Date | Thu, 12 Oct 2017 12:24:19 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH 2/3] early_printk: Add force_early_printk kernel parameter |
| |
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@infradead.org> > --- > 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.
| |