Messages in this thread | | | Date | Wed, 12 Mar 2014 15:34:56 +0100 | From | Jan Kara <> | Subject | Re: is printk() safe within a timekeeper_seq write section? |
| |
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@chello.nl > > 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@suse.cz> SUSE Labs, CR
| |