From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Date: Tue, 4 Jul 2006 08:32:26 +0200 Message-ID: <20060704063225.GA2752@elte.hu> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Return-path: Received: from mx3.mail.elte.hu ([157.181.1.138]:30411 "EHLO mx3.mail.elte.hu") by vger.kernel.org with ESMTP id S1750739AbWGDGhD (ORCPT ); Tue, 4 Jul 2006 02:37:03 -0400 To: Nathan Scott Content-Disposition: inline In-Reply-To: <20060704112503.H1495869@wobbly.melbourne.sgi.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org * Nathan Scott wrote: > > > While trying to remove 2 small files, 2 empty dirs and 1 empty dir > > > on xfs partition > > > > Probably spurious. xfs_ilock can be called on both the parent and > > child, which wouldn't be a deadlock. > > Hmm... they'd be different inodes though, so different lock addresses > in memory - is lockdep taking that into account? Would we need to go > annotate xfs_ilock somehow to give better hints to the lockdep code? correct, lockdep has to be taught about relations between locks within the same lock-class. (it detects relations between different lock-classes automatically) It's usually a straightforward process. In this particular case we probably need to do something similar to the VFS's 'enum inode_i_mutex_lock_class' subclass categorizations: we need xfs_ilock_nested(.., subclass), where in xfs_lock_dir_and_entry() we'd pass in ILOCK_PARENT. [normal locking calls have a default subclass ID of 0] I suspect simply creating an XFS filesystem and doing a couple of VFS ops on it should trigger these locking patterns? Ingo