On Tue, Jul 04, 2006 at 08:32:26AM +0200, Ingo Molnar wrote: > > * Nathan Scott <nathans@xxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
