Re: 3.14.0+/x86: lockdep and mutexes not getting along

From: Kirill A. Shutemov
Date: Thu Apr 10 2014 - 05:16:47 EST


On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
> On Wed, 2014-04-09 at 15:19 +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 <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
> > > state.
> > >
> > > Reported-by: Ingo Molnar <mingo@xxxxxxxxxx>
> > > Signed-off-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > > Cc: jason.low2@xxxxxx
>
> Hello,
>
> As a starting point, would either of you like to test the following
> patch to see if it fixes the issue? This patch essentially generates the
> same code as in older kernels in the debug case. This applies on top of
> kernels with both commits 6f008e72cd11 and 1d8fe7dc8078.

I'm not able to trigger the lockdep report with the patch applied so far.

--
Kirill A. Shutemov
--
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/