linux-kernel - Re: [git pull] scheduler fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Aug 2008 11:01:00 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Miller <davem@...emloft.net>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, a.p.zijlstra@...llo.nl
Subject: Re: [git pull] scheduler fixes


* David Miller <davem@...emloft.net> wrote:

> From: David Miller <davem@...emloft.net>
> 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?

	Ingo
--
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/