[Top] [All Lists]

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

To: Lachlan McIlroy <lachlan@xxxxxxx>
Subject: Re: [PATCH] Allocate inode tracing buffers before locking inode cluster
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 18 Aug 2008 18:14:03 +1000
Cc: xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <48A92BC6.5020105@xxxxxxx>
Mail-followup-to: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
References: <48A92BC6.5020105@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
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....


Dave Chinner

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