[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49C8C792.2080509@in.ibm.com>
Date: Tue, 24 Mar 2009 17:14:18 +0530
From: Sachin Sant <sachinp@...ibm.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
CC: linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
linuxppc-dev@...abs.org
Subject: Next March 24: Inconsistent lock state trace
Hi Stephen,
I had today's next tree compiled and booted on a powerpc box.
While compiling a kernel on the same box saw the following trace
on console.
=================================
[ INFO: inconsistent lock state ]
2.6.29-next-20090324 #3
---------------------------------
inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
yum-updatesd-he/24903 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&inode->inotify_mutex){+.+.?.}, at: [<c000000000152678>] .inotify_inode_queue_event+0x6c/0x160
{IN-RECLAIM_FS-W} state was registered at:
[<c000000000097634>] .lock_acquire+0x108/0x154
[<c00000000058a308>] .mutex_lock_nested+0x78/0x460
[<c000000000152824>] .inotify_inode_is_dead+0x38/0xcc
[<c00000000012f970>] .dentry_iput+0xa8/0x134
[<c00000000012fb90>] .d_kill+0x68/0xac
[<c00000000012fec0>] .__shrink_dcache_sb+0x2ec/0x3b4
[<c000000000130254>] .shrink_dcache_memory+0x134/0x214
[<c0000000000e9810>] .shrink_slab+0x144/0x20c
[<c0000000000e9b50>] .try_to_free_pages+0x278/0x3d4
[<c0000000000e1eb0>] .__alloc_pages_internal+0x2c8/0x498
[<c00000000010bc40>] .alloc_page_vma+0x120/0x14c
[<c0000000000f4e20>] .handle_mm_fault+0x1b8/0x888
[<c00000000058e564>] .do_page_fault+0x394/0x5b0
[<c000000000005330>] handle_page_fault+0x20/0x5c
irq event stamp: 182173
hardirqs last enabled at (182173): [<c000000000111fec>] .kmem_cache_alloc+0xe8/0x14c
hardirqs last disabled at (182172): [<c000000000111b18>] .__slab_alloc+0x298/0x518
softirqs last enabled at (181818): [<c00000000002bab4>] .call_do_softirq+0x14/0x24
softirqs last disabled at (181803): [<c00000000002bab4>] .call_do_softirq+0x14/0x24
other info that might help us debug this:
4 locks held by yum-updatesd-he/24903:
#0: (&type->i_mutex_dir_key#4){+.+.+.}, at: [<c00000000012a6cc>] .do_filp_open+0x188/0x874
#1: (&inode->inotify_mutex){+.+.?.}, at: [<c000000000152678>] .inotify_inode_queue_event+0x6c/0x160
#2: (&ih->mutex){+.+...}, at: [<c0000000001526a8>] .inotify_inode_queue_event+0x9c/0x160
#3: (&dev->ev_mutex){+.+...}, at: [<c000000000153f98>] .inotify_dev_queue_event+0x50/0x1d8
stack backtrace:
Call Trace:
[c000000044c1b560] [c0000000000115f4] .show_stack+0x70/0x184 (unreliable)
[c000000044c1b610] [c000000000093cd4] .print_usage_bug+0x1bc/0x1ec
[c000000044c1b6c0] [c000000000094080] .mark_lock+0x37c/0x6c0
[c000000044c1b770] [c00000000009441c] .mark_held_locks+0x58/0xac
[c000000044c1b800] [c0000000001141ec] .__kmalloc+0x88/0x194
[c000000044c1b8b0] [c000000000153eac] .kernel_event+0xbc/0x158
[c000000044c1b950] [c000000000154068] .inotify_dev_queue_event+0x120/0x1d8
[c000000044c1ba00] [c0000000001526f8] .inotify_inode_queue_event+0xec/0x160
[c000000044c1bad0] [c000000000127d28] .vfs_create+0x168/0x1e4
[c000000044c1bb70] [c00000000012a780] .do_filp_open+0x23c/0x874
[c000000044c1bd10] [c000000000119124] .do_sys_open+0x80/0x140
[c000000044c1bdc0] [c00000000015f0f0] .compat_sys_open+0x24/0x38
[c000000044c1be30] [c000000000008554] syscall_exit+0x0/0x40
==============================
Not too sure what to infer from the above trace :-(
Haven't seen this trace with previous next tree's.
Have attached .config here, just in case it helps.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
View attachment "config_next_20090324" of type "text/plain" (75955 bytes)
Powered by blists - more mailing lists