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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180304104324.6bbbaa53@gandalf.local.home>
Date:   Sun, 4 Mar 2018 10:43:24 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Qixuan.Wu" <qixuan.wu@...ux.alibaba.com>
Cc:     "linux-kernel-owner" <linux-kernel-owner@...r.kernel.org>,
        "Petr Mladek" <pmladek@...e.com>, "Jan Kara" <jack@...e.cz>,
        "linux-kernel" <linux-kernel@...r.kernel.org>,
        "Sergey Senozhatsky" <sergey.senozhatsky@...il.com>,
        "chenggang.qin" <chenggang.qin@...ux.alibaba.com>,
        "caijingxian" <caijingxian@...ux.alibaba.com>,
        "yuanliang.wyl" <yuanliang.wyl@...baba-inc.com>
Subject: Re: Would you help to tell why async printk solution was not taken
 to upstream kernel ?

On Sun, 04 Mar 2018 23:08:23 +0800
"Qixuan.Wu" <qixuan.wu@...ux.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