linux-kernel - Re: is printk() safe within a timekeeper

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]

Date:	Wed, 12 Mar 2014 16:06:17 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jan Kara <jack@...e.cz>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <john.stultz@...aro.org>,
	Jiri Bohac <jbohac@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: is printk() safe within a timekeeper_seq write section?

On Wed, Mar 12, 2014 at 03:34:56PM +0100, Jan Kara wrote:
> On Wed 12-03-14 07:46:45, Peter Zijlstra wrote:
> > On Tue, Mar 11, 2014 at 10:32:26PM +0100, Thomas Gleixner wrote:
> > > > Peter/Thomas: Any thoughts on the deferred printk buffer? Does printk
> > > > already have something like this? Any other ideas here?
> > > 
> > > I was thinking about something like that for RT as on RT printk is a
> > > complete nightmare. It's simple to implement that, but as we know from
> > > the RT experience it can lead to painful loss of debug output.
> > > 
> > > Assume you printk inside such a region, which just fills the dmesg
> > > buffer and schedules the delayed output. Now in that same region you
> > > run into a deadlock which causes the whole machine to freeze. Then you
> > > won't see the debug output, which might actually give you the hint why
> > > the system deadlocked ....
> > 
> > Ok so I started writing a rant that I don't give a crap about klogd and
> > that deferring that wakeup would be perfectly fine; then I looked at the
> > code and found that we in fact do this already.
> > 
> > wake_up_klogd() schedules a lazy irqwork to go wake up, so that's out.
> > 
> > That leaves the console sem wakeup; but I suppose we could redo this
> > patch:
> > 
> >   lkml.kernel.org/r/20110621153806.286257129@...llo.nl
> > 
> > to get rid of that one.
>   I don't know if you've noticed but there's also the following patch:
> https://lkml.org/lkml/2013/12/23/310
>   which would make it pretty easy to just add messages to printk buffer in
> timer code and schedule printing later using irq work.

Yeah; I suppose that one is prettier.

>   Regarding your referenced patch - the way it is written, it would make
> all printk users spin on console_sem->lock all the time while we are
> flushing buffer to console. I don't think we want that - we trylock the
> console_sem exactly so that other printk users can proceed while one poor
> guy is pushing stuff to console.

That should be fixable though; just keep enough state for the other
printk()s to see they don't need to also flush.

But the idea is to not do the sleep+wakeup dance.

But as stated; that's not going to actually matter much, since the
popular console drivers are crap and do wakeups too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/