xfs
[Top] [All Lists]

Re: [PATCH] Allocate inode tracing buffers before locking inode cluster

To: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Subject: Re: [PATCH] Allocate inode tracing buffers before locking inode cluster
From: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Tue, 19 Aug 2008 13:52:59 +1000
In-reply-to: <20080818081403.GJ19760@disturbed>
References: <48A92BC6.5020105@xxxxxxx> <20080818081403.GJ19760@disturbed>
Reply-to: lachlan@xxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080707)
Dave Chinner wrote:
On Mon, Aug 18, 2008 at 05:59:02PM +1000, Lachlan McIlroy wrote:
Trying to allocate memory while holding the inode cluster locked can cause
deadlocks; a thread creating an inode will have the inode cluster locked
and is stuck allocating memory, pdflush/kswapd are both trying to push out
dirty pages and convert delayed allocations which need space in the log and
xfsaild is trying to push on the tail of the log but is stuck trying to
acquire the inode cluster lock.

I tried fixing this with KM_NOFS but turned a two-way deadlock into a
three-way deadlock.  This patch moves the allocation of the inode tracing
buffers before we lock the inode cluster.  We can also leak memory because
we don't free these allocations if we return from this function early so
use xfs_idestroy() to fully clean up the inode first.

Seems sane, but I think it should be wrapped up in the
xfs_inode_alloc() code added as part of the 'Make use of the
init-once slab optimisation' patch I posted recently. This
moves the initialisation of all things inode related into a
separate function - xfs_inode_alloc() - instead of doing all
these intialisations around the place....


Okay, sounds like a good idea.  I'll pull that patch in first.


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