| To: | David Chinner <dgc@xxxxxxx> |
|---|---|
| Subject: | Re: lockdep annotations? |
| From: | Lachlan McIlroy <lachlan@xxxxxxx> |
| Date: | Tue, 04 Sep 2007 10:51:44 +1000 |
| Cc: | Christian Kujau <lists@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <20070903090103.GG734179@xxxxxxx> |
| References: | <alpine.DEB.0.999.0709012300030.6640@xxxxxxxxxxxxxxxxxx> <46DB7586.7040309@xxxxxxx> <20070903090103.GG734179@xxxxxxx> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Thunderbird 2.0.0.4 (X11/20070604) |
David Chinner wrote: 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. Yep. This is just another case where we've confused lockdep. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: raid50 and 9TB volumes, Christian Kujau |
|---|---|
| Next by Date: | Re: raid50 and 9TB volumes, Eric Sandeen |
| Previous by Thread: | Re: lockdep annotations?, David Chinner |
| Next by Thread: | Start Sending Video Emails In Minutes, mwpoz |
| Indexes: | [Date] [Thread] [Top] [All Lists] |