Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Another\s+questionable\s+lock\s+order\s+bug\s*$/: 3 ]

Total 3 documents matching your query.

1. Another questionable lock order bug (score: 1)
Author: Nick Piggin <npiggin@xxxxxxxxx>
Date: Sat, 18 Dec 2010 04:40:23 +1100
With the iprune_sem and iolock lock order warnings taken care of, lockdep soon after chokes on i_lock [ 716.364005] inconsistent {RECLAIM_FS-ON-R} -> {IN-RECLAIM_FS-W} usage. [ 716.364005] cp/8370 [H
/archives/xfs/2010-12/msg00279.html (10,626 bytes)

2. Re: Another questionable lock order bug (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 18 Dec 2010 10:54:09 +1100
What kernel are you running? It does not appear to be vanilla XFS, as: ^^^^^^^^^^^^^^^^^ This patch is not yet mainline. If you really want to do significant XFS scalability testing for .38, you shou
/archives/xfs/2010-12/msg00282.html (12,234 bytes)

3. Re: Another questionable lock order bug (score: 1)
Author: Nick Piggin <npiggin@xxxxxxxxx>
Date: Sat, 18 Dec 2010 13:05:05 +1100
It's just vanilla plus your patch to fix iolock and Christoph's iprune patch to fix that one -- lockdep doesn't get very far without them. OK I'll keep it in mind, however in this case I was stress t
/archives/xfs/2010-12/msg00284.html (14,683 bytes)


This search system is powered by Namazu