Re: is printk() safe within a timekeeper_seq write section?

[Jan Kara]

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@xxxxxxxxx
> 
> 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.

  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.

								Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/