inconsistent lock state

=================================
[ INFO: inconsistent lock state ]
2.6.34 #1
---------------------------------
inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. kswapd0/227 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&(&ip->i_iolock)->mr_lock#2){++++?+}, at: [<ffffffff8112c11f>]

xfs_ilock+0x27/0x79 {RECLAIM_FS-ON-W} state was registered at:
  [<ffffffff810510f5>] mark_held_locks+0x52/0x70
  [<ffffffff81051198>] lockdep_trace_alloc+0x85/0x9f
  [<ffffffff81073db2>] __alloc_pages_nodemask+0x7b/0x5b5
  [<ffffffff8106f1e2>] grab_cache_page_write_begin+0x65/0xaa
  [<ffffffff810bfaaa>] block_write_begin+0x38/0xcd
  [<ffffffff81146f1f>] xfs_vm_write_begin+0x25/0x27
  [<ffffffff8106e140>] generic_file_buffered_write+0x114/0x271
  [<ffffffff8114aa31>] xfs_file_aio_write+0x4e1/0x70c
  [<ffffffff8109d187>] do_sync_write+0xc6/0x103
  [<ffffffff8109db5f>] vfs_write+0xad/0x172
  [<ffffffff8109dcdd>] sys_write+0x45/0x6c
  [<ffffffff81001f2b>] system_call_fastpath+0x16/0x1b
irq event stamp: 62175
hardirqs last  enabled at (62175): [<ffffffff8126fb03>]
_raw_spin_unlock_irqrestore+0x3a/0x60 hardirqs last disabled at
(62174): [<ffffffff8126f3a9>] _raw_spin_lock_irqsave+0x17/0x58 softirqs
last  enabled at (61572): [<ffffffff8103398d>] __do_softirq+0x127/0x13e
softirqs last disabled at (61543): [<ffffffff81002dcc>]
call_softirq+0x1c/0x28

other info that might help us debug this:
2 locks held by kswapd0/227:
#0: (shrinker_rwsem){++++..}, at: [<ffffffff810797f0>]

shrink_slab+0x38/0x144 #1:  (&xfs_mount_list_lock){++++.-}, at:
[<ffffffff811503fc>] xfs_reclaim_inode_shrink+0x35/0x128

stack backtrace:
Pid: 227, comm: kswapd0 Not tainted 2.6.34 #1
Call Trace:
 [<ffffffff81050b72>] print_usage_bug+0x1a4/0x1b5
 [<ffffffff8100c995>] ? save_stack_trace+0x2a/0x47
 [<ffffffff810516bc>] ? check_usage_forwards+0x0/0xcf
 [<ffffffff81050e6d>] mark_lock+0x2ea/0x520
 [<ffffffff81052b8a>] __lock_acquire+0x6c1/0x1607
 [<ffffffff8116820b>] ? radix_tree_delete+0xd1/0x1d0
 [<ffffffff81053b27>] lock_acquire+0x57/0x6d
 [<ffffffff8112c11f>] ? xfs_ilock+0x27/0x79
 [<ffffffff81046939>] down_write_nested+0x2a/0x4d
 [<ffffffff8112c11f>] ? xfs_ilock+0x27/0x79
 [<ffffffff8112c11f>] xfs_ilock+0x27/0x79
 [<ffffffff8112c2eb>] xfs_ireclaim+0x93/0xb1
 [<ffffffff8114f949>] xfs_reclaim_inode+0x1de/0x20a
 [<ffffffff81150299>] xfs_inode_ag_walk+0x8b/0xe6
 [<ffffffff8114f76b>] ? xfs_reclaim_inode+0x0/0x20a
 [<ffffffff81150374>] xfs_inode_ag_iterator+0x80/0xd3
 [<ffffffff8114f76b>] ? xfs_reclaim_inode+0x0/0x20a
 [<ffffffff81150428>] xfs_reclaim_inode_shrink+0x61/0x128
 [<ffffffff8107988b>] shrink_slab+0xd3/0x144
 [<ffffffff81079c61>] balance_pgdat+0x365/0x59b
 [<ffffffff81077908>] ? isolate_pages_global+0x0/0x212
 [<ffffffff8107a089>] kswapd+0x1f2/0x20f
 [<ffffffff81042e89>] ? autoremove_wake_function+0x0/0x34
 [<ffffffff8126fb24>] ? _raw_spin_unlock_irqrestore+0x5b/0x60
 [<ffffffff81079e97>] ? kswapd+0x0/0x20f
 [<ffffffff81042ac7>] kthread+0x7a/0x82
 [<ffffffff81002cd4>] kernel_thread_helper+0x4/0x10
 [<ffffffff8126ff40>] ? restore_args+0x0/0x30
 [<ffffffff81042a4d>] ? kthread+0x0/0x82
 [<ffffffff81002cd0>] ? kernel_thread_helper+0x0/0x10

It's a false positive introduced in 2.6.34 by the inode shrinker. That's one of several different false positive traces in 2.6.34, but I can't do anything about them because the shrinkers require global scope. The patches to customise the shrinker contexts (which avoids all of these warnings) will fix this....

You may as well not run lockdep on anything with an XFS filesystem, as these false positives will occur as soon as memory reclaim triggers and turn lockdep off.

Cheers,

Dave.

Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs