xfs
[Top] [All Lists]

Re: [PATCH 4/4] V2 xfs: fix deadlock in xfs_rtfree_extent with kernel v2

To: Kamal Dasu <kdasu.kdev@xxxxxxxxx>
Subject: Re: [PATCH 4/4] V2 xfs: fix deadlock in xfs_rtfree_extent with kernel v2.6.37
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sat, 25 Feb 2012 04:40:30 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <33379323.post@xxxxxxxxxxxxxxx>
References: <33345988.post@xxxxxxxxxxxxxxx> <33346009.post@xxxxxxxxxxxxxxx> <33346035.post@xxxxxxxxxxxxxxx> <33346043.post@xxxxxxxxxxxxxxx> <33346051.post@xxxxxxxxxxxxxxx> <20120219224118.GA31535@xxxxxxxxxxxxx> <33365485.post@xxxxxxxxxxxxxxx> <33379323.post@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Feb 23, 2012 at 08:52:57AM -0800, Kamal Dasu wrote:
> 
> To fix the deadlock caused by recursively calling xfs_rtfree_extent
> from xfs_bunmapi():
> 
>  - removed  xfs_trans_iget() from xfs_rtfree_extent(),
>    instead added asserts that the inode is locked and has an inode_item
>    attached to it.
>  - in xfs_bunmapi() when dealing with an inode with the rt flag
>    call xfs_ilock() and xfs_trans_ijoin() so that the
>    reference count is bumped on the inode and attached it to the
>    transaction before calling into xfs_bmap_del_extent, similar to
>    what we do in xfs_bmap_rtalloc.
> 
> Signed-off-by: Kamal Dasu <kdasu.kdev@xxxxxxxxx>

This looks good, thanks a lot!

Do you have an easily reproducable testcase for this which we could
put into xfstests?

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