On Wed, Nov 24, 2010 at 11:58:11AM +1100, Nick Piggin wrote: > On Wed, Nov 24, 2010 at 08:12:58AM +1100, Dave Chinner wrote: > > On Tue, Nov 23, 2010 at 11:18:02PM +1100, Nick Piggin wrote: > > > Hi, > > > > > > IIRC I've reported this before. Perhaps it is a false positive, but even > > > so it is still annoying that it triggers and turns off lockdep for > > > subsequent debugging. > > > > > > Any chance it can get fixed or properly annotated? > > > > 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? > > Hmm. I suppose that should work. > > So xfs_reclaim_inode can only call xfs_ilock _after_ the Linux inode > has gone through ->evict_inode call? I think so - it's only found by xfs_reclaim_inode() if the radix tree reclaim tag is set for the inode, which is only set in two places: ->destroy_inode(), and in a failed lookup (which doesn't touch the iolock). I can't see any other way we can get to an inode in reclaim... > If so, then let's ask the lockdep people. Sure. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
