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

[Kamal Dasu]

Christoph,

I have not been able to create a simple test case for this yet.

Currently the only way I have is to use an a time shift recording
application 
that stores video streams on a real-time subvolume.  Sometimes when such
a stream is deleted I see the problem. I have not  figured out how to create
a 
test to consistently get allocation where the bit map span multiple extents
while 
freeing  the inode. 

I am still trying to come with a simple test case. 
If you have any ideas let me know I will be happy to try it out.

I have also posted a equivalent post for the 3.3 kernel branch.
http://old.nabble.com/-PATCH--xfs%3A-fix-deadlock-in-xfs_rtfree_extent-with-kernel-v3.x-to33375114.html

Please let me know if 

Kamal



Christoph Hellwig wrote:
> 
> 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 at gmail.com>
> 
> This looks good, thanks a lot!
> 
> Do you have an easily reproducable testcase for this which we could
> put into xfstests?
> 
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 
> 

-- 
View this message in context: http://old.nabble.com/-PATCH-0-4--RFC-xfs%3A-resurrect-realtime-subvolume-support-on-kernel-2.6.37-tp33345988p33390983.html
Sent from the Xfs - General mailing list archive at Nabble.com.