Ah sorry, I resent the old lockdep patches, Will send the real one
ASAP.
On Tue, Aug 25, 2009 at 02:21:34PM -0400, Christoph Hellwig wrote:
> Currently we take the iolock in the reclaim path in various places.
> Taking it in the inode reclaim path means however that we can't take
> it while doing memory allocations that recurse back into the filesystem,
> and recently lockdep has been enhanced to find these cases and noticed
> quite a few of these in XFS.
>
> We had similar issues with the ilock, but we could get away with just
> stopping to do filesystem-recursing allocation under the ilock as there
> were just a few. The iolock is however taken over larger critical sections
> protection actual I/O and it's almost impossible to switch all these to
> NOFS allocations. Based on what the iolock is used for we don't actually
> need it in the reclaim path, though - at this point the inode is dead
> and no one has any other reference to it. See the listing in the
> first patch for a more detailed list of our current iolock holders and
> why they can't contend with the reclaim path.
>
> I would greatly appreciate some indepth-review of this to make sure I
> haven't missed a big loophole..
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
---end quoted text---
|