[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1360032122.27007.4.camel@gandalf.local.home>
Date: Mon, 04 Feb 2013 21:42:02 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [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
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists