Re: [PATCH next v4 1/2] lib/dump_stack: move cpu lock to printk.c

[Petr Mladek]

On Thu 2021-06-17 09:32:43, Steven Rostedt wrote:
> On Thu, 17 Jun 2021 11:56:50 +0206
> John Ogness <john.ogness@xxxxxxxxxxxxx> wrote:
> 
> > dump_stack() implements its own cpu-reentrant spinning lock to
> > best-effort serialize stack traces in the printk log. However,
> > there are other functions (such as show_regs()) that can also
> > benefit from this serialization.
> > 
> > Move the cpu-reentrant spinning lock (cpu lock) into new helper
> > functions printk_cpu_lock_irqsave()/printk_cpu_unlock_irqrestore()
> > so that it is available for others as well. For !CONFIG_SMP the
> > cpu lock is a NOP.
> > 
> > Note that having multiple cpu locks in the system can easily
> > lead to deadlock. Code needing a cpu lock should use the
> > printk cpu lock, since the printk cpu lock could be acquired
> > from any code and any context.
> > 
> > Also note that it is not necessary for a cpu lock to disable
> > interrupts. However, in upcoming work this cpu lock will be used
> > for emergency tasks (for example, atomic consoles during kernel
> > crashes) and any interruptions while holding the cpu lock should
> > be avoided if possible.
> > 
> > Signed-off-by: John Ogness <john.ogness@xxxxxxxxxxxxx>
> > ---
> 
> Can we add this lock to early_printk() ?
> 
> This would make early_printk() so much more readable.

Good point! Just to be sure. Do you see the messed output with plain
kernel? Or do you need the extra patches (from Peter Zijlstra) that
redirect normal printk() to early_printk()?

My understanding is that early_printk() is used only for very early
boot message in plain kernel. And that there is not much concurrency
at that time.

That said. I always wanted to upstream Peter's patchset. But I never
found time to clean it up.

Best Regards,
Petr