On Wed, Nov 24, 2010 at 03:03:41PM -0500, Christoph Hellwig wrote: > On Wed, Nov 24, 2010 at 08:12:58AM +1100, Dave Chinner wrote: > > It is supposed to be handled by the re-initialisation of the > > ip->i_iolock in ->evict_inode (xfs_fs_evict_inode). An inode found > > in the reclaim state must have passed through this reinitialisation, > > so from a lockdep perspective the iolock in the vfs path is a > > different context to the iolock in the reclaim path. That fixed all > > the non-reclaim state related lockdep false positives, so Perhaps > > there is an issue with the lockdep reclaim state checking that does > > not interact well with re-initialised lock contexts? > > I've been looking through this again, and I think it's indeed not > enough. We don't just need to re-initialize it, but also set a > different lockclass for it. Doesn't init_rwsem give it a new class? Guys, can you take a quick look at the code Dave is referring to (xfs_fs_evict_inode), and check that it actually does what he intends? We're getting what seems to be false positives in reclaim inversion of lockings. Backtraces here http://oss.sgi.com/pipermail/xfs/2010-November/048092.html Thanks, Nick _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
