On Wed, Apr 09, 2014 at 03:19:40PM +0300, Kirill A. Shutemov wrote:
> On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
> > 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
> > commit 6f008e72cd111a119b5d8de8c5438d892aae99eb
> > Author: Peter Zijlstra <pet...@infradead.org>
> > 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
> > state.
> >
> > Reported-by: Ingo Molnar <mi...@kernel.org>
> > Signed-off-by: Peter Zijlstra <pet...@infradead.org>
> > Cc: jason.l...@hp.com
> > Link:
> > http://lkml.kernel.org/r/20140312122442.gb27...@twins.programming.kicks-ass.net
> > Signed-off-by: Ingo Molnar <mi...@kernel.org>
> >
> > :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.
So what does lockdep say when it messes up your p4?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
