On Mon, 2013-02-04 at 18:09 -0800, Andrew Morton wrote: > I don't think so. Conceptually printk() should be "inner" to the > scheduler and shouldn't call into sched things at all. The (afaik > sole) exception to that was the klogd wakeup. > > Traditionally the deadlock happened when calling printk() with > tasklist_lock (now q->lock) held. printk() would call wake_up(klogd) > and wake_up() tries to take tasklist_lock and boom. Moving the > wake_up() out to the tick "thread" fixed that. > > Maybe there were other deadlock scenarios, dunno. That knowledge > appears to be disappearing into the mists of time :(
Even without the printk irq_work the current printk method uses a delayed wakeup anyway. The wake_up_klogd() sets PRINTK_PENDING_WAKEUP, and the wakeup happens at time of the tick. I don't see where there is a deadlock. I added a printk in __sched_setscheduler() where the run queue lock is held, and booted that with full lockdep debugging enabled. No deadlock is detected. Do we really even need that printk_sched()? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
