Messages in this thread | | | Date | Wed, 12 Mar 2014 07:46:45 +0100 | From | Peter Zijlstra <> | Subject | Re: is printk() safe within a timekeeper_seq write section? |
| |
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.
| |