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/[email protected] 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/[email protected] Since that whole printk recursion + zap_locks thing is terminally broken. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
