From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Richter Subject: 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory) Date: Wed, 1 Sep 2010 08:37:43 +0200 (CEST) Message-ID: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Cc: linux-kernel@vger.kernel.org To: linux-fsdevel@vger.kernel.org Return-path: Received: from einhorn.in-berlin.de ([192.109.42.8]:39251 "EHLO einhorn.in-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752209Ab0IAGhq (ORCPT ); Wed, 1 Sep 2010 02:37:46 -0400 Content-Disposition: INLINE Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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: [] shrink_icache_memory+0x48/0x217 {RECLAIM_FS-ON-W} state was registered at: [] mark_held_locks+0x4d/0x6b [] lockdep_trace_alloc+0x8e/0xa7 [] kmem_cache_alloc+0x2a/0xc8 [] fsnotify_create_event+0x39/0x160 [] send_to_group+0x108/0x13f [] fsnotify+0x167/0x266 [] fsnotify_unmount_inodes+0xb8/0xf9 [] invalidate_inodes+0x4b/0x13a [] generic_shutdown_super+0x42/0xd2 [] kill_block_super+0x22/0x3a [] deactivate_locked_super+0x21/0x41 [] deactivate_super+0x40/0x44 [] mntput_no_expire+0xdc/0x10a [] sys_umount+0x2a4/0x2d1 [] system_call_fastpath+0x16/0x1b irq event stamp: 281663 hardirqs last enabled at (281663): [] __call_rcu+0x119/0x125 hardirqs last disabled at (281662): [] __call_rcu+0x28/0x125 softirqs last enabled at (278242): [] __do_softirq+0x14a/0x15b softirqs last disabled at (278217): [] call_softirq+0x1c/0x28 other info that might help us debug this: 1 lock held by kswapd0/436: #0: (shrinker_rwsem){++++..}, at: [] shrink_slab+0x38/0x164 stack backtrace: Pid: 436, comm: kswapd0 Not tainted 2.6.36-rc3 #3 Call Trace: [] print_usage_bug+0x1af/0x1c0 [] ? check_usage_forwards+0x0/0xcd [] mark_lock+0x2eb/0x51a [] __lock_acquire+0x862/0x182c [] ? shrink_dcache_memory+0x114/0x1a9 [] ? shrink_dcache_memory+0x11d/0x1a9 [] ? shrink_dcache_memory+0x114/0x1a9 [] lock_acquire+0x5a/0x71 [] ? shrink_icache_memory+0x48/0x217 [] down_read+0x42/0x55 [] ? shrink_icache_memory+0x48/0x217 [] shrink_icache_memory+0x48/0x217 [] shrink_slab+0xe1/0x164 [] kswapd+0x590/0x7e2 [] ? autoremove_wake_function+0x0/0x38 [] ? _raw_spin_unlock_irqrestore+0x4c/0x68 [] ? kswapd+0x0/0x7e2 [] kthread+0x81/0x89 [] kernel_thread_helper+0x4/0x10 [] ? finish_task_switch+0x69/0xa9 [] ? restore_args+0x0/0x30 [] ? kthread+0x0/0x89 [] ? 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/