Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*next\-20090220\:\s+XFS\:\s+inconsistent\s+lock\s+state\s*$/: 7 ]

Total 7 documents matching your query.

1. next-20090220: XFS: inconsistent lock state (score: 1)
Author: Alexander Beregalov <a.beregalov@xxxxxxxxx>
Date: Fri, 20 Feb 2009 20:52:59 +0300
Hi [ INFO: inconsistent lock state ] 2.6.29-rc5-next-20090220 #2 -- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. kswapd0/324 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&ip->i_lock)->mr_lock){+++
/archives/xfs/2009-02/msg00383.html (10,566 bytes)

2. Re: next-20090220: XFS: inconsistent lock state (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 24 Feb 2009 15:07:40 -0500
That's a false positive. While the ilock can be taken in reclaim the allocation here is done before the inode is added to the inode cache. The patch below should help avoiding the warning: Index: xfs
/archives/xfs/2009-02/msg00449.html (9,391 bytes)

3. Re: next-20090220: XFS: inconsistent lock state (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Tue, 03 Mar 2009 10:00:01 -0600
Seems ok to me. I hate to see the BUG() added but I guess in this case something truly bizarre would have to happen for the ilock to fail on this inode. on irc you sugggested ASSERT(0); instead of BU
/archives/xfs/2009-03/msg00007.html (10,851 bytes)

4. Re: next-20090220: XFS: inconsistent lock state (score: 1)
Author: Felix Blyakher <felixb@xxxxxxx>
Date: Tue, 3 Mar 2009 10:45:28 -0600
[ INFO: inconsistent lock state ] 2.6.29-rc5-next-20090220 #2 -- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. kswapd0/324 [HC0[0]:SC0[0]:HE1:SE1] takes: xfs_ilock+0xaa/0x120 {RECLAIM_FS
/archives/xfs/2009-03/msg00009.html (11,073 bytes)

5. Re: next-20090220: XFS: inconsistent lock state (score: 1)
Author: Felix Blyakher <felixb@xxxxxxx>
Date: Tue, 3 Mar 2009 10:57:07 -0600
[ INFO: inconsistent lock state ] 2.6.29-rc5-next-20090220 #2 -- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. kswapd0/324 [HC0[0]:SC0[0]:HE1:SE1] takes: xfs_ilock+0xaa/0x120 {RECLAIM_FS
/archives/xfs/2009-03/msg00011.html (12,457 bytes)

6. Re: next-20090220: XFS: inconsistent lock state (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 3 Mar 2009 12:02:48 -0500
Ok, let's keep the BUG for now and I'll throw in your error undwinding fix. Will resend the series for 2.6.29 patches after QAing them.
/archives/xfs/2009-03/msg00012.html (9,140 bytes)

7. Re: next-20090220: XFS: inconsistent lock state (score: 1)
Author: Alexander Beregalov <a.beregalov@xxxxxxxxx>
Date: Fri, 6 Mar 2009 12:30:53 +0300
Hi Is it the same issue? [ INFO: inconsistent lock state ] 2.6.29-rc7-next-20090305 #8 -- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. kswapd0/318 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&ip-
/archives/xfs/2009-03/msg00038.html (13,271 bytes)


This search system is powered by Namazu