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