Messages in this thread | | | Date | Wed, 23 Jan 2008 12:27:12 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: [PATCH 01/20 -v5] printk - dont wakeup klogd with interrupts disabled |
| |
On Wed, 23 Jan 2008, Daniel Walker wrote:
> > On Wed, 2008-01-23 at 11:02 -0500, Steven Rostedt wrote: > > > + if (!irqs_disabled() && wake_klogd) > > wake_up_klogd(); > > This causes a regression .. When printk is called during an OOPS in > kernels without this change then the OOPS will get logged, since the > logging process (klogd) is woken to handle the messages.. If you apply > this change klogd doesn't wakeup, and hence doesn't log the oops.. So if > you remove the wakeup here you have to add it someplace else to maintain > the logging .. > > (I'm not theorizing here, I have defects logged against this specific > piece of code..)
It wont get woken up anyway. Did you look at wake_up_klogd?
void wake_up_klogd(void) { if (!oops_in_progress && waitqueue_active(&log_wait)) wake_up_interruptible(&log_wait); }
So if oops_in_progress is set, then it still wont get woken. Perhaps it got woken some other way? Or is oops_in_progress not set in these oops?
One other solution is to make the runqueue locks visible externally. Like:
in sched.c:
int runqueue_is_locked(void) { int cpu = get_cpu(); struct rq *rq = cpu_rq(cpu); int ret;
ret = spin_is_locked(&rq->lock); put_cpu(); return ret; }
And in printk we could do:
if (wake_klogd && !runqueue_is_locked()) wake_up_klogd();
This probably is the cleanest solution since it simply prevents the deadlock from occurring.
-- Steve
| |