linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael L. Semon" <mlsemon35@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: 3.14.0+/x86: lockdep and mutexes not getting along
Date: Sun, 6 Apr 2014 01:12:14 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LNX.2.11.1404060059020.8208@bpserver.ds> (raw)

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@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 <mingo@kernel.org>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: jason.low2@hp.com
    Link: http://lkml.kernel.org/r/20140312122442.GB27965@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@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.

Thanks!

Michael


             reply	other threads:[~2014-04-06  5:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-06  5:12 Michael L. Semon [this message]
2014-04-09 12:19 ` 3.14.0+/x86: lockdep and mutexes not getting along Kirill A. Shutemov
2014-04-10  5:42   ` Jason Low
2014-04-10  8:14     ` Peter Zijlstra
2014-04-10  9:15     ` Kirill A. Shutemov
2014-04-10 11:42       ` Peter Zijlstra
2014-04-10  9:18     ` Peter Zijlstra
2014-04-10 14:15       ` Peter Zijlstra
2014-04-11 13:59         ` Valdis.Kletnieks
2014-04-14  7:22         ` [tip:core/urgent] locking/mutex: Fix debug_mutexes tip-bot for Peter Zijlstra
2014-04-10 17:14       ` 3.14.0+/x86: lockdep and mutexes not getting along Jason Low
2014-04-10 17:28         ` Peter Zijlstra
2014-04-10 19:04           ` Jason Low
2014-04-10 23:26         ` Dave Jones
2014-04-10 23:30           ` Dave Jones
2014-04-11  3:48           ` Paul E. McKenney
2014-04-11 13:41     ` Michael L. Semon
2014-04-10  8:12   ` Peter Zijlstra
2014-04-10  8:13   ` Peter Zijlstra
2014-04-10 14:29   ` cred_guard_mutex vs seq_file::lock [was: Re: 3.14.0+/x86: lockdep and mutexes not getting along] Peter Zijlstra
2014-04-11 14:50   ` David Howells
2014-04-11 15:07     ` Al Viro
2014-07-30 22:31       ` Kirill A. Shutemov
2014-07-30 23:03         ` Kirill A. Shutemov
2014-07-31  7:26         ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.11.1404060059020.8208@bpserver.ds \
    --to=mlsemon35@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).