linux-kernel - Re: [PATCH] printk: avoid livelock if another CPU printks continuously

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: <56BB6A66.6020502@hurleysoftware.com>
Date:	Wed, 10 Feb 2016 08:50:46 -0800
From:	Peter Hurley <peter@...leysoftware.com>
To:	Steven Rostedt <rostedt@...dmis.org>,
	Petr Mladek <pmladek@...e.com>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>, linux-kernel@...r.kernel.org,
	srostedt@...hat.com, Tejun Heo <tj@...nel.org>,
	Jan Kara <jack@...e.com>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kyle McMartin <kyle@...nel.org>,
	KY Srinivasan <kys@...rosoft.com>,
	Dave Jones <davej@...emonkey.org.uk>,
	Calvin Owens <calvinowens@...com>
Subject: Re: [PATCH] printk: avoid livelock if another CPU printks
 continuously

On 02/10/2016 08:25 AM, Steven Rostedt wrote:
> On Wed, 10 Feb 2016 17:10:16 +0100
> Petr Mladek <pmladek@...e.com> wrote:
> 
>>> Note, it's not that performance critical, and the loop only happens if
>>> someone else is adding to the console, which hopefully, should be rare.  
>>
>> I probably used too strong words. It is possible that the performance
>> impact will not be critical. But the behavior is non-deterministic.
>> I think that the approach taken by Jack is more promising.
>> I mean the offloading of the console stuff to a workqueue.
> 
> My worry about that is that it never comes out. The point about printk,
> is that it should pretty much be guaranteed to print. If the system is
> dying, and we push it off to a work queue, and that workqueue never
> runs, then we lose critical data.

I agree.

I thought a more promising approach was Pan Xinhui's patch from August [1]
which hands off console output to the incoming cpu. The reqd state machine
is described in more detail in the revised patch [2].

Unfortunately, the patch was abandoned. I think he may have misunderstood
when I also referred to Jack's patches; I meant to simply draw attention
to concurrent work for review and comparison.


[1] original https://lkml.org/lkml/2015/8/11/333
[2] revised https://lkml.org/lkml/2015/8/12/321