| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: XFS reclaim lock order bug, Dave Chinner |
|---|---|
| Next by Date: | xfs: add FITRIM support, Christoph Hellwig |
| Previous by Thread: | Re: XFS reclaim lock order bug, Dave Chinner |
| Next by Thread: | Re: XFS reclaim lock order bug, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |