Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756724Ab2FDJ32 (ORCPT ); Mon, 4 Jun 2012 05:29:28 -0400 Received: from merlin.infradead.org ([205.233.59.134]:45861 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750973Ab2FDJ31 convert rfc822-to-8bit (ORCPT ); Mon, 4 Jun 2012 05:29:27 -0400 Message-ID: <1338802157.28282.7.camel@twins> Subject: Re: processes hung after sys_renameat, and 'missing' processes From: Peter Zijlstra To: Linus Torvalds Cc: Dave Jones , Al Viro , Linux Kernel Date: Mon, 04 Jun 2012 11:29:17 +0200 In-Reply-To: References: <20120603223617.GB7707@redhat.com> <20120604000059.GA14144@redhat.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Evolution 3.2.2- Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1557 Lines: 37 On Sun, 2012-06-03 at 17:16 -0700, Linus Torvalds wrote: > On Sun, Jun 3, 2012 at 5:00 PM, Dave Jones wrote: > > > > sysrq-d: http://fpaste.org/ow9O/ > > Ugh. I'm adding PeterZ to the cc, just to see if he can make more sense of it. > > Peter, is there no way to make the lock thing print not just the lock > class name, but also the pointer to the actual *instance* of the lock > held? Sorta, we have a pointer to the struct lockdep_map inside whatever lock type. But we don't have the lock type so we cannot actually provide the pointer to the spinlock_t struct mutex etc.. > Also, it's a bit unclear to me, but I *think* that most of those users > don't actually "hold" the lock - they are waiting for it. Yes/no? Yes, this is waiting to acquire, lockdep started out with 2 hooks, one before the actual acquire and one on release. Its done before the actual acquire so we can warn before we lock up in case of an actual deadlock. > Does > the lockdep information have the capability to distinguish between > "waiting for" vs "actually successfully owns the lock"? Sometimes.. when build with lockstat we have enough hooks to do this. I suppose I could make all those hooks available for all of lockdep and track the per lock state more accurate in order to improve this printout. -- 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/