linux-kernel - 3.14.0+/x86: lockdep and mutexes not getting along

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 6 Apr 2014 01:12:14 -0400 (EDT)
From:	"Michael L. Semon" <mlsemon35@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: 3.14.0+/x86: lockdep and mutexes not getting along

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@...earer:/usr/src/kernel-git/linux# git bisect good
6f008e72cd111a119b5d8de8c5438d892aae99eb is the first bad commit
commit 6f008e72cd111a119b5d8de8c5438d892aae99eb
Author: Peter Zijlstra <peterz@...radead.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@...nel.org>
    Signed-off-by: Peter Zijlstra <peterz@...radead.org>
    Cc: jason.low2@...com
    Link: http://lkml.kernel.org/r/20140312122442.GB27965@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@...nel.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/