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*. -- 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
|