On Mon, Sep 03, 2007 at 12:46:30PM +1000, Lachlan McIlroy wrote:
> This is a locking inversion between the iolock and iprune_mutex. I
> hadn't seen this one before. Was your system running low on memory
> at the time?
>
> We can't drop the iolock in the write path so we'll have to avoid
> acquiring the iolock in xfs_ireclaim() which means we'll need another
> way to synchronise with xfs_sync_inodes().
I don't think a deadlock exists here - we have to be going through
memory reclaim to hit this inversion, so the only place that we
can deadlock is if we are holding the iprune_mutex across a memory
allocation. I don't think we do that....
Not to mention that the inode we hold the iolock on won't be on the
inode free list so we won't ever try to lock it during reclaim, either.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|