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