* 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? Ingo - 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
