[Top] [All Lists]

Re: XFS reclaim lock order bug

To: Nick Piggin <npiggin@xxxxxxxxx>
Subject: Re: XFS reclaim lock order bug
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 24 Nov 2010 13:26:39 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20101124005811.GC3168@amd>
References: <20101123121802.GA4785@amd> <20101123211258.GY22876@dastard> <20101124005811.GC3168@amd>
User-agent: Mutt/1.5.20 (2009-06-14)
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.



Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>