From: Andrew Morton <akpm@linux-foundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [GIT PULL] printk: Support for full dynticks mode
Date: Mon, 4 Feb 2013 20:04:59 -0800 [thread overview]
Message-ID: <20130204200459.f2a0a1cc.akpm@linux-foundation.org> (raw)
In-Reply-To: <1360032122.27007.4.camel@gandalf.local.home>
On Mon, 04 Feb 2013 21:42:02 -0500 Steven Rostedt <rostedt@goodmis.org> wrote:
> 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.
>
> ...
>
> Do we really even need that printk_sched()?
3ccf3e8306156a282 ("printk/sched: Introduce special printk_sched() for
those awkward moments") was added _after_ wake_up_klogd() was switched
to using the printk_pending->printk_tick() thing. So presumably there
were deadlocks other than around wake_up_klogd().
The printk_pending->printk_tick() thing was added by b845b517b5e
("printk: robustify printk"), four years earlier in 2008. It says
"Avoid deadlocks against rq->lock and xtime_lock...".
So what deadlocks was the March 2012 3ccf3e830 ("printk/sched:
Introduce special printk_sched() for those awkward moments") supposed
to fix? grr. I searched my lkml archives for March 2012 and few
preceding months, but couldn't find any additional info.
> 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.
Well, you'd need to enable various printk options to get full coverage.
For example, that xtime_lock deadlock would only have occurred when
timestamping is enabled.
next prev parent reply other threads:[~2013-02-05 4:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-05 0:51 [GIT PULL] printk: Support for full dynticks mode Frederic Weisbecker
2013-02-05 1:20 ` Andrew Morton
2013-02-05 1:22 ` Steven Rostedt
2013-02-05 1:37 ` Frederic Weisbecker
2013-02-05 2:09 ` Andrew Morton
2013-02-05 2:42 ` Steven Rostedt
2013-02-05 4:04 ` Andrew Morton [this message]
2013-02-05 12:05 ` Ingo Molnar
2013-02-05 3:14 ` Steven Rostedt
2013-02-05 3:19 ` Frederic Weisbecker
2013-02-05 3:24 ` Steven Rostedt
2013-02-05 3:29 ` Steven Rostedt
2013-02-05 12:13 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130204200459.f2a0a1cc.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox