[lkml]   [2013]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] printk: Support for full dynticks mode
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

Do we really even need that printk_sched()?

-- Steve

 \ /
  Last update: 2013-02-05 04:21    [W:0.047 / U:3.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site