xfs
[Top] [All Lists]

Re: XFS reclaim lock order bug

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS reclaim lock order bug
From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Date: Thu, 25 Nov 2010 11:36:44 +0100
Cc: Nick Piggin <npiggin@xxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, Ingo Molnar <mingo@xxxxxxxxxx>
In-reply-to: <20101125102940.GE12187@dastard>
References: <20101123121802.GA4785@amd> <20101123211258.GY22876@dastard> <20101124200341.GA2493@xxxxxxxxxxxxx> <20101125034824.GA3359@amd> <1290666325.2072.535.camel@laptop> <20101125102940.GE12187@dastard>
On Thu, 2010-11-25 at 21:29 +1100, Dave Chinner wrote:

> > In that case though, it would suggest the inode got re-used instead of
> > destroyed and re-created using xfs_alloc_inode(), is that at all
> > possible?
> 
> Yes, actually it is - see the XFS_IRECLAIMABLE case in
> xfs_iget_cache_hit(). I guess we haven't seen the original lock
> inversion false positives that this was supposed to fix because the
> reclaim warnings trip first...
> 
> I think that means we also need to reinitialise the lock when we recycle
> the inode out of the XFS_IRECLAIMABLE state.

Right, in which case you probably want an explicit lock class and use
that one class in both xfs_alloc_inode() and the reclaim case.

See my earlier suggestion wrt lockdep_set_class*() on how to do that.

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