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: <20160209115722.02508617@gandalf.local.home>
Date:	Tue, 9 Feb 2016 11:57:22 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Denys Vlasenko <dvlasenk@...hat.com>
Cc:	linux-kernel@...r.kernel.org, srostedt@...hat.com,
	Tejun Heo <tj@...nel.org>,
	Peter Hurley <peter@...leysoftware.com>
Subject: Re: [PATCH] printk: avoid livelock if another CPU printks
 continuously

On Tue, 09 Feb 2016 17:41:25 +0100
Denys Vlasenko <dvlasenk@...hat.com> wrote:

 
> > No, I mentioned the taking of console sem. The spamming task will be
> > trying that a bit, failing and then letting this CPU continue doing its
> > bidding.  
> 
> That's exactly what we *don't* want to happen.
> We want that other CPU to get the lock.

I know. I meant that if the task fails to get the lock, it will let the
other continue to do its bidding. Hence the multiple tries. But this is
moot, because it's just adding onto the hacks.


> 
> How do you plan to achieve that, if not by giving it a grace period
> when it can grab a lock?

What really needs to be done is to find out why a CPU is spamming with
printks and fix that. Is it a bug that is triggering?

-- Steve