lkml.org 
[lkml]   [2014]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.




\
 
 \ /
  Last update: 2014-03-12 08:21    [W:0.101 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site