* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Tue, Jan 17, 2017 at 03:56:54PM +0100, Peter Zijlstra wrote: > > On Tue, Jan 17, 2017 at 03:55:32PM +0100, Peter Zijlstra wrote: > > > On Sun, Jan 15, 2017 at 06:24:08AM +0100, Mike Galbraith wrote: > > > > git blames locking/ww_mutex: Optimize ww-mutexes by waking at most one waiter for backoff when acquiring the lock > > > > > > > [ 0.000000] ------------[ cut here ]------------ > > > > [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff+0x8d/0xb0 > > > > > > > [ 0.000000] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 > > > > [ 0.000000] Call Trace: > > > > [ 0.000000] warn_slowpath_null+0x1d/0x20 > > > > [ 0.000000] __ww_mutex_wakeup_for_backoff+0x8d/0xb0 > > > > [ 0.000000] __ww_mutex_lock.constprop.10+0x3ae/0x13d0 > > > > [ 0.000000] ww_mutex_lock+0x42/0x70 > > > > [ 0.000000] ww_test_edeadlk_normal+0x1e9/0x220 > > > > > > OK, I can reproduce. This looks like the lockdep_assert_held() I added > > > to replace a comment... Just not quite sure how we can get here without > > > actually holding that lock. > > > > > > /me goes poke at it. > > > > Oh duh, MUTEX_DEBUG uses arch_spin_lock() for wait_lock... *groan*. > > Ingo, how about something like so? Lockdep should be able to tell us > about the interrupt cruft real quick, I don't see why we should > hand-craft this anymore. Sounds good to me! Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|