[Top] [All Lists]

Re: XFS reclaim lock order bug

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: XFS reclaim lock order bug
From: Nick Piggin <npiggin@xxxxxxxxx>
Date: Thu, 25 Nov 2010 14:48:24 +1100
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Nick Piggin <npiggin@xxxxxxxxx>, xfs@xxxxxxxxxxx, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>
In-reply-to: <20101124200341.GA2493@xxxxxxxxxxxxx>
References: <20101123121802.GA4785@amd> <20101123211258.GY22876@dastard> <20101124200341.GA2493@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
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

We're getting what seems to be false positives in reclaim inversion
of lockings. Backtraces here


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