Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755925Ab0FXPkY (ORCPT ); Thu, 24 Jun 2010 11:40:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51899 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755891Ab0FXPkW (ORCPT ); Thu, 24 Jun 2010 11:40:22 -0400 Date: Thu, 24 Jun 2010 17:40:02 +0200 (CEST) From: John Kacur X-X-Sender: jkacur@localhost.localdomain To: Nick Piggin , Peter Zijlstra , john stultz , Thomas Gleixner cc: linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org Subject: lockdep "splat" on v2.6.33.5-rt23 Message-ID: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2860 Lines: 72 I believe this is related to the dcache scale discussion thread. I've shown this to Peter privately, but thought it would be useful to share it with everyone so we all have the same info. The kernel is from tip/rt/2.6.33 up to commit faf35813f204901f85dd0c6b3c5092e0064c6c2f It has a lot of debug options enabled, but is not modified. The "splat" is very easy to reproduce, it simply occurs when I boot the kernel on my T500. ============================================= [ INFO: possible recursive locking detected ] 2.6.33.5-rt23-tip-debug #3 --------------------------------------------- init/1 is trying to acquire lock: (&dentry->d_lock/1){+.+...}, at: [] shrink_dcache_parent+0x10f/0x2eb but task is already holding lock: (&dentry->d_lock/1){+.+...}, at: [] shrink_dcache_parent+0x10f/0x2eb other info that might help us debug this: 2 locks held by init/1: #0: (&dentry->d_lock){+.+...}, at: [] shrink_dcache_parent+0xdf/0x2eb #1: (&dentry->d_lock/1){+.+...}, at: [] shrink_dcache_parent+0x10f/0x2eb stack backtrace: Pid: 1, comm: init Not tainted 2.6.33.5-rt23-tip-debug #3 Call Trace: [] __lock_acquire+0xcb9/0xd35 [] ? shrink_dcache_parent+0x10f/0x2eb [] lock_acquire+0xd4/0xf1 [] ? shrink_dcache_parent+0x10f/0x2eb [] rt_spin_lock_nested+0x3d/0x44 [] ? shrink_dcache_parent+0x10f/0x2eb [] ? dentry_lru_del_init+0x3e/0xa8 [] ? shrink_dcache_parent+0xdf/0x2eb [] shrink_dcache_parent+0x10f/0x2eb [] proc_flush_task+0xd4/0x26f [] release_task+0x47/0x650 [] wait_consider_task+0x9ba/0x10b4 [] do_wait+0x17d/0x38b [] sys_wait4+0xf6/0x119 [] ? sysret_check+0x27/0x62 [] ? child_wait_callback+0x0/0xa5 [] system_call_fastpath+0x16/0x1b [jkacur@tycho tip-rt-2.6.33]$ addr2line -e vmlinux ffffffff811981be /home/jkacur/rt.linux.git/fs/dcache.c:1033 [jkacur@tycho tip-rt-2.6.33]$ addr2line -e vmlinux ffffffff8119818e /home/jkacur/rt.linux.git/fs/dcache.c:1023 So that is function static int select_parent(struct dentry * parent) line 1023 is spin_lock(&this_parent->d_lock); and lines 1032 and 1033 are spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED); dentry_lru_del_init(dentry); If there is any other info I can provide to help solve this, or testing etc, pls let me know! John Kacur -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/