Re: Serial console is causing system lock-up

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (03/12/19 13:08), Petr Mladek wrote:
> > 2. You seem unwilling to acknowledge the difference between emergency
> >    and informational messages. A message is either critical or it is
> >    not. If it is, it should be handled as such, regardless of
> >    interference, regardless if it means turning an SMP machine into a UP
> >    machine. If it is not critical, it should be sent along a
> >    non-interfering path so the the system is _not_ affected.
> 
> This means that any critical message is always more important than any
> workload. It opens doors for iteresting DOS attacks.

Agreed.

So what I thought about "mutual exclusive error reporting with
quadratic latencies" was that if any workload involves error
reporting then it might be a good idea to _not_ parallelize such
workload anymore.

> > The current printk implementation is handling all console printing as
> > best effort. Trying hard enough to dramatically affect the system, but
> > not trying hard enough to guarantee success.
>
> I agree that direct output is more reliable. It might be very useful
> for debugging some types of problems. The question is
> if it is worth the cost (code complexity, serializing CPUs
> == slowing down the entire system).

Agreed.

I'm very skeptical about "serializing CPUs" part. It looks like one
"print or die trying" is replaced with another "print or die trying".
What happened to  log_store() + flush_on_panic()?

	-ss