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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
