2.6.36-rc3: inconsistent lock state (iprune_sem,shrink_icache_memory)

[Stefan Richter]

I switched from 2.6.35 to 2.6.36-rc3 a few days ago and while doing so
enabled lockdep.  Just got the following report during normal desktop
usage:

=================================
[ INFO: inconsistent lock state ]
2.6.36-rc3 #3
---------------------------------
inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage.
kswapd0/436 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (iprune_sem){+++++-}, at: [<ffffffff810bde0b>] shrink_icache_memory+0x48/0x217
{RECLAIM_FS-ON-W} state was registered at:
  [<ffffffff810598b3>] mark_held_locks+0x4d/0x6b
  [<ffffffff8105995f>] lockdep_trace_alloc+0x8e/0xa7
  [<ffffffff810a5a7f>] kmem_cache_alloc+0x2a/0xc8
  [<ffffffff810d4f8a>] fsnotify_create_event+0x39/0x160
  [<ffffffff810d49e8>] send_to_group+0x108/0x13f
  [<ffffffff810d4b86>] fsnotify+0x167/0x266
  [<ffffffff810d57d0>] fsnotify_unmount_inodes+0xb8/0xf9
  [<ffffffff810bda9b>] invalidate_inodes+0x4b/0x13a
  [<ffffffff810ad3e5>] generic_shutdown_super+0x42/0xd2
  [<ffffffff810ad497>] kill_block_super+0x22/0x3a
  [<ffffffff810aca61>] deactivate_locked_super+0x21/0x41
  [<ffffffff810acc39>] deactivate_super+0x40/0x44
  [<ffffffff810c1c29>] mntput_no_expire+0xdc/0x10a
  [<ffffffff810c2e5d>] sys_umount+0x2a4/0x2d1
  [<ffffffff81001feb>] system_call_fastpath+0x16/0x1b
irq event stamp: 281663
hardirqs last  enabled at (281663): [<ffffffff81072d32>] __call_rcu+0x119/0x125
hardirqs last disabled at (281662): [<ffffffff81072c41>] __call_rcu+0x28/0x125
softirqs last  enabled at (278242): [<ffffffff81038cff>] __do_softirq+0x14a/0x15b
softirqs last disabled at (278217): [<ffffffff81002e8c>] call_softirq+0x1c/0x28

other info that might help us debug this:
1 lock held by kswapd0/436:
 #0:  (shrinker_rwsem){++++..}, at: [<ffffffff810891d7>] shrink_slab+0x38/0x164

stack backtrace:
Pid: 436, comm: kswapd0 Not tainted 2.6.36-rc3 #3
Call Trace:
 [<ffffffff8105933b>] print_usage_bug+0x1af/0x1c0
 [<ffffffff81059e81>] ? check_usage_forwards+0x0/0xcd
 [<ffffffff81059637>] mark_lock+0x2eb/0x51a
 [<ffffffff8105af8c>] __lock_acquire+0x862/0x182c
 [<ffffffff810ba6ea>] ? shrink_dcache_memory+0x114/0x1a9
 [<ffffffff810ba6f3>] ? shrink_dcache_memory+0x11d/0x1a9
 [<ffffffff810ba6ea>] ? shrink_dcache_memory+0x114/0x1a9
 [<ffffffff8105bfb0>] lock_acquire+0x5a/0x71
 [<ffffffff810bde0b>] ? shrink_icache_memory+0x48/0x217
 [<ffffffff8133cb68>] down_read+0x42/0x55
 [<ffffffff810bde0b>] ? shrink_icache_memory+0x48/0x217
 [<ffffffff810bde0b>] shrink_icache_memory+0x48/0x217
 [<ffffffff81089280>] shrink_slab+0xe1/0x164
 [<ffffffff81089893>] kswapd+0x590/0x7e2
 [<ffffffff8104b1d6>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8133deff>] ? _raw_spin_unlock_irqrestore+0x4c/0x68
 [<ffffffff81089303>] ? kswapd+0x0/0x7e2
 [<ffffffff8104ade2>] kthread+0x81/0x89
 [<ffffffff81002d94>] kernel_thread_helper+0x4/0x10
 [<ffffffff8102d5ba>] ? finish_task_switch+0x69/0xa9
 [<ffffffff8133e3c0>] ? restore_args+0x0/0x30
 [<ffffffff8104ad61>] ? kthread+0x0/0x89
 [<ffffffff81002d90>] ? kernel_thread_helper+0x0/0x10


A web search finds reports of this kind from months ago.  I haven't read
up on them yet whether there were any conclusions from them.
-- 
Stefan Richter
-=====-==-=- =--= ----=
http://arcgraph.de/sr/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/