3.14.0+/x86: lockdep and mutexes not getting along
From: Michael L. Semon
Date: Sun Apr 06 2014 - 01:13:10 EST
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a splat will happen, lockdep will shut
itself off, and my i686 Pentium 4 PC will continue. Now, after the
splat, it will allow one key of input at either a VGA console or over
serial. After that, only the magic SysRq keys and KDB still work.
File activity stops, and many processes are stuck in the D state.
Bisect brought me here:
root@plbearer:/usr/src/kernel-git/linux# git bisect good
6f008e72cd111a119b5d8de8c5438d892aae99eb is the first bad commit
Author: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Date: Wed Mar 12 13:24:42 2014 +0100
locking/mutex: Fix debug checks
OK, so commit:
1d8fe7dc8078 ("locking/mutexes: Unlock the mutex without the wait_lock")
generates this boot warning when CONFIG_DEBUG_MUTEXES=y:
WARNING: CPU: 0 PID: 139 at /usr/src/linux-2.6/kernel/locking/mutex-debug.c:82 debug_mutex_unlock+0x155/0x180() DEBUG_LOCKS_WARN_ON(lock->owner != current)
And that makes sense, because as soon as we release the lock a
new owner can come in...
One would think that !__mutex_slowpath_needs_to_unlock()
implementations suffer the same, but for DEBUG we fall back to
mutex-null.h which has an unconditional 1 for that.
The mutex debug code requires the mutex to be unlocked after
doing the debug checks, otherwise it can find inconsistent
Reported-by: Ingo Molnar <mingo@xxxxxxxxxx>
Signed-off-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>
:040000 040000 80e40c2009942a31f98127c4f9fa958f34b3947b f46ed4b70c4f30fc665fe8f810d3c13920cd765a M kernel
Indeed, my issues are solved (so far) simply by reverting this commit.
Might someone test lockdep on x86 to see if this is a consistent
issue that needs to be adjusted? My lockdep splats are generated by
running xfstests test generic/113 on XFS, but splats caused by other
issues should still create the same symptoms.
Otherwise, this 3.15 kernel has been rather kind to me so far.
PC is an i686 Pentium 4 with 1280 MB RAM and old IDE hardware,
running Slackware 14.1.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/