Re: printk deadlock due to double lock attempt on current CPU's runqueue

[John Ogness <john.ogness@linutronix.de>]

On 2021-11-10, Daniel Vetter <daniel@ffwll.ch> wrote:
> I'm a bit out of the loop but from lwn articles my understanding is
> that part of upstreaming from -rt we no longer have the explicit "I'm
> a safe console for direct printing" opt-in. Which I get from a
> backwards compat pov, but I still think for at least fbcon we really
> should never attempt a direct printk con->write, it's just all around
> terrible.

Right now we don't have an explicit "I'm a safe console for direct
printing" option. Right now all printing is direct. But it sounds to me
that we should add this console flag when we introduce kthread printers.

> So yeah for fbcon at least I think we really should throw out direct
> con->write from printk completely.

Even after we introduce kthread printers, there will still be situations
where direct printing is used: booting (before kthreads exist) and
shutdown/suspend/crash situations, when the kthreads may not be
active.

I will introduce a console flag so that consoles can opt-out for direct
printing. (opt-out rather than opt-in is probably easier, since there
are only a few that would need to opt-out).

Since kthread printers do not yet exist (hoping to get them in for
5.17), I am not sure how we should address the reported bug for existing
kernels.

John Ogness