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

[Peter Zijlstra <peterz@infradead.org>]

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@chello.nl

to get rid of that one.

However, at that point we run into the fact that many console drivers do
wakeups themselves. I did fix 8250, because that is in fact the only
console I really care about, but in general Linus said to give up and
deal with the fact that console drivers suck already (or something along
those lines).

And while I was looking at all that; I got reminded that I really need
to respin this one:

  lkml.kernel.org/r/20111221111143.511565321@chello.nl

Since that whole printk recursion + zap_locks thing is terminally
broken.