Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752145AbaDFFM1 (ORCPT ); Sun, 6 Apr 2014 01:12:27 -0400 Received: from mail-qc0-f179.google.com ([209.85.216.179]:58512 "EHLO mail-qc0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750812AbaDFFMT (ORCPT ); Sun, 6 Apr 2014 01:12:19 -0400 Date: Sun, 6 Apr 2014 01:12:14 -0400 (EDT) From: "Michael L. Semon" To: linux-kernel@vger.kernel.org Subject: 3.14.0+/x86: lockdep and mutexes not getting along Message-ID: User-Agent: Alpine 2.11 (LNX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 Signed-off-by: Peter Zijlstra Cc: jason.low2@hp.com Link: http://lkml.kernel.org/r/20140312122442.GB27965@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar :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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/