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
|