[lkml]   [2008]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [git pull] scheduler fixes

* David Miller <> wrote:

> From: David Miller <>
> Date: Thu, 31 Jul 2008 15:55:04 -0700 (PDT)
> > I am absolutely sure, I spent the whole night yesterday trying to
> > debug this.
> Followup. I lost two days of my life debugging this because seemingly
> nobody can friggin' agree on what to do about the "printk() wakeup
> issue". Thanks!
> Can we fix this now, please?
> The problem was that Peter's patch triggers a print_deadlock_bug() in
> lockdep.c on the runqueue locks.
> But those printk()'s quickly want to do a wakeup, which wants to take
> the runqueue lock this thread already holds. So I would only get the
> first line of the lockdep debugging followed by a complete hang.

ugh. In the context of lockdep you are the first one to trigger this bug
- thanks for the fix!

We had a few other incidents of printks generated by bugs within the
scheduler code causing lockups (due to the wakeup) - and Steve Rostedt
sent a more generic solution for that: to first trylock the runqueue
lock in that case instead of doing an unconditional wakeup.

The patch made it to linux-next but Andrew NAK-ed that patch because it
caused other problems: it made printk wakeups conceptually less
reliable. (a spurious lock taken from another CPU could prevent a printk
wakeup from propagating and could block klogd indefinitely)

> Doing these wakeups in such a BUG message is unwise. Please can we
> apply something like the following and save other developers countless
> wasted hours of their time?
> Thanks :-)

applied to tip/core/locking.

I'm wondering, does this mean that Peter's:

lockdep: change scheduler annotation

is still not good enough yet?


 \ /
  Last update: 2008-08-01 11:03    [W:0.095 / U:22.240 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site