Re: [LOCKDEP] xfs: possible recursive locking detected

[Nathan Scott <nathans@sgi.com>]

On Tue, Jul 04, 2006 at 08:32:26AM +0200, Ingo Molnar wrote:
> 
> * Nathan Scott <nathans@sgi.com> 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?

Yep, looks like its really easy to trigger - I pulled Linus' tree,
enabled everything I could see that looked lockdep related and I
immediately saw warnings during bootup... that was with an XFS root,
should be able to hit it pretty quickly with any simple filesystem
interaction though (root or not).

cheers.

-- 
Nathan