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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.