Messages in this thread | | | Date | Thu, 17 Jan 2008 20:57:51 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: [PATCH] printk deadlocks if called with runqueue lock held |
| |
On Thu, 17 Jan 2008, Andrew Morton wrote: > > A "well-known" problem which few know about ;)
And now I feel less ignorant.
> > Anyway you should be developing with all debug options enabled and that > includes NMI watchdog so there.
hehe, I did have NMI on the whole time. It's that I also had modifications in try_to_wakeup, so seeing that in the backtrace, I thought I was the one screwing up. But I was still certain that it was my code locking up.
> > > > Calling printk with interrupts disabled should only be done for > > emergencies and debugging anyway. > >
> > + * held, this will deadlock. We don't have access to the runqueue > > + * lock from here, but just checking for interrupts disabled > > + * should be enough. > > + */ > > + if (!irqs_disabled() && wake_klogd) > > wake_up_klogd(); > > } > > EXPORT_SYMBOL(release_console_sem); > > this looks fairly foul. Might cause problems if one CPU is stuck with > interrupts off spewing printks?
Well, we have more than one problem if that is happening.
> > Couldn't you maintain a sched-hackers-only printk patch which adds a > sched_printk() which avoids the wakeup or something like that? >
Actually, the code that did trigger it was part of the latency_tracer code doing the wakeup latency timings. Theres a printk that happens when we trigger the max latency, and it prints from the scheduler.
So this was perfect to lock up every time.
-- Steve
| |