Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

[Steven Rostedt]

On Fri, 27 May 2016 16:56:01 +0200
Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote:

> >We use to have a patch where a console could flag itself as atomic.
> >That is, that it doesn't call any sleeping locks. What happened to that.
> >
> >IIRC, the video console was one such console. Otherwise, we lose out on
> >backtraces in irq context.  
> 
> video, like VT?
> The call_console_drivers() does not check such a flag and I don't
> remember about removing something like that. I was actually thinking

You probably didn't remove it. It may have been removed a while ago
when Thomas did his big rewrite to get things working again.

> about adding such a flagâ I remember you had something in your tree to
> print from IRQ off regions via UART.

I had a few hacks for a while, but they were nothing more than hacks.

Perhaps we should make a better early_printk() or simple console for RT
that can handle printk in atomic locations.

I have a hack patch that gives early_printk() a new "spin lock", where
it only takes the lock if the owner isn't on the CPU. Otherwise it
allows lock to continue (and wont release it). That hack was required
to get legible output from early_printk() when I was getting a bunch of
crashes on all the CPUs, because early_printk() has no locks, and the
console is just a mess when all CPUs print at once.

> 
> We don't print from a context with interrupts disabled or even a preempt
> disabled region. In such cases we just wake_up_klogd() and print it
> later.

Yeah, but that doesn't help if the "later" never comes.

> The reason for the patch was the HW/SW lockup detector which comes with
> interrupts disabled or NMI context and gets to the console(s). Usually
> we defer everything until later except in this case. And I got busted
> later in the VT code (and the problem was that one sleeping while atomic
> warning which led to more stuff to be printed).

Yeah, it's a pain where our output needs to be in schedulable context.

-- Steve