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

[Dave Chinner <david@fromorbit.com>]

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....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com