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

[Lachlan McIlroy <lachlan@sgi.com>]

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.