XFS reclaim lock order bug

[Nick Piggin]

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? If so, then let's ask the lockdep
people.

Thanks,
Nick