Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965238AbaDJIN7 (ORCPT ); Thu, 10 Apr 2014 04:13:59 -0400 Received: from merlin.infradead.org ([205.233.59.134]:36218 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933287AbaDJIN4 (ORCPT ); Thu, 10 Apr 2014 04:13:56 -0400 Date: Thu, 10 Apr 2014 10:13:48 +0200 From: Peter Zijlstra To: "Kirill A. Shutemov" Cc: "Michael L. Semon" , Ingo Molnar , jason.low2@hp.com, linux-kernel@vger.kernel.org Subject: Re: 3.14.0+/x86: lockdep and mutexes not getting along Message-ID: <20140410081348.GJ10526@twins.programming.kicks-ass.net> References: <20140409121940.GA12890@node.dhcp.inet.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140409121940.GA12890@node.dhcp.inet.fi> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > 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. 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 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/