Re: Boot stall regression from "printk for 5.19" merge

[Linus Torvalds]

On Mon, Jun 20, 2022 at 6:44 AM Petr Mladek <pmladek@xxxxxxxx> wrote:
>
> Both early console and proper console driver has its own kthread.
>
> >    1.166486] f0512000.serial: ttyS0 at MMIO 0xf0512000 (irq = 22, base_baud = 12500000) is a 16550A
>
> The line is malformed. I wonder if both early console and proper
> console used the same port in parallel.

Honestly, I get the feeling that we need to just revert the whole
"console from thread" thing.

Because:

> So, it looks like that con->write() code is not correctly serialized
> between the early and normal console.
> [ ... ]
> I am going to check the driver...

We really cannot be in the situation that some random driver that used
to work no longer does, and causes oopses and/or memory corruption
just because it's now entered differently from how it traditionally
has been.

The traditional console write code has always been very careful to get
exclusive access, and it sounds like that is just plain broken now.

So I don't think this is a "driver is broken". Even if you find a fix
for it that makes that particular configuration happy, it sounds like
there is a much more fundamental issue at hand: the new printk code
just doesn't work well, and does things that are against the way
console printing has always worked in the past.

I realize that people have wanted to do printing from proper thread
context for ages and ages.

But maybe people should also just admit that "I wanted this" was not
"this was actually a good idea".

                  Linus