Re: Would you help to tell why async printk solution was not taken to upstream kernel ?

[Steven Rostedt <rostedt@goodmis.org>]

On Sun, 04 Mar 2018 23:08:23 +0800
"Qixuan.Wu" <qixuan.wu@linux.alibaba.com> wrote:

> Suppose there is one scenario that the system has 100 CPU(0~99). While CPU 0 is 
> calling slow console, CPU 1~99 are calling printk at the same time. And suppose 
> CPU 1 will be waiter, as per the patch, 2~99 will return directly. After CPU 0 finish 
> it's log to console, it will return when it finds CPU 1 are waiting. Then CPU 1 need 
> flush all logs of CPU(1~99) to the console, which may cause  softlockup or rcu 
> stall. Above scenario is very unusual and it's very unlikely to happen. 

Yes, people keep bringing up this scenario.

It would require a single burst of printks to all CPUs. And then no
more printks after that. The last one will end up printing the entire
buffer out the slow console. The thing is, this is a bounded time, and
no printk will print more than one full buffer worth.

If this is a worry, then set the timeouts for the lockup detection to
be longer than the time it takes to print one full buffer with the
slowest console.

-- Steve