| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: creating a new 80 TB XFS, Roger Willcocks |
|---|---|
| Next by Date: | Re: creating a new 80 TB XFS, Martin Steigerwald |
| Previous by Thread: | [PATCH 4/4] V2 xfs: fix deadlock in xfs_rtfree_extent with kernel v2.6.37, Kamal Dasu |
| Next by Thread: | Re: [PATCH 4/4] V2 xfs: fix deadlock in xfs_rtfree_extent with kernel v2.6.37, Kamal Dasu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |