From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946225AbWJSQx7 (ORCPT ); Thu, 19 Oct 2006 12:53:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1946227AbWJSQx6 (ORCPT ); Thu, 19 Oct 2006 12:53:58 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]:59811 "EHLO rgminet01.oracle.com") by vger.kernel.org with ESMTP id S1946225AbWJSQx6 (ORCPT ); Thu, 19 Oct 2006 12:53:58 -0400 Date: Thu, 19 Oct 2006 09:53:38 -0700 From: Mark Fasheh To: Srinivasa Ds Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, Joel Becker Subject: Re: Issues with possible recursive locking Message-ID: <20061019165338.GC10128@ca-server1.us.oracle.com> Reply-To: Mark Fasheh References: <4535A89E.9070609@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4535A89E.9070609@in.ibm.com> Organization: Oracle Corporation User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 18, 2006 at 09:37:58AM +0530, Srinivasa Ds wrote: > When I was removing dlm module,I hit in to below error. This patch should take care of that particular warning, please let me know if it doesn't. I'll carry it in ocfs2.git shortly. Hmm, I get other warnings from configfs starting and stopping the ocfs2 cluster stack, so I bet we've got some more mutex_lock() calls in there to change to mutex_lock_nested(): [ INFO: possible recursive locking detected ] 2.6.19-rc2 #1 --------------------------------------------- o2cb_ctl/2457 is trying to acquire lock: (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 but task is already holding lock: (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 other info that might help us debug this: 2 locks held by o2cb_ctl/2457: #0: (&inode->i_mutex/1){--..}, at: [] lookup_create+0x1d/0x73 #1: (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 stack backtrace: [] dump_trace+0x64/0x1c2 [] show_trace_log_lvl+0x12/0x25 [] show_trace+0xd/0x10 [] dump_stack+0x19/0x1b [] __lock_acquire+0x6c6/0x8e3 [] lock_acquire+0x4b/0x6c [] __mutex_lock_slowpath+0xb0/0x1f6 [] mutex_lock+0x21/0x24 [] configfs_add_file+0x36/0x60 [configfs] [] configfs_create_file+0x35/0x38 [configfs] [] configfs_attach_item+0x13d/0x180 [configfs] [] configfs_attach_group+0x14/0x154 [configfs] [] configfs_attach_group+0xd4/0x154 [configfs] [] configfs_mkdir+0x1b2/0x287 [configfs] [] vfs_mkdir+0xca/0x131 [] sys_mkdirat+0x88/0xbb [] sys_mkdir+0x10/0x12 [] syscall_call+0x7/0xb --Mark configfs: mutex_lock_nested() fix configfs_unregister_subsystem() nests a pair of inode i_mutex acquisitions, and thus needs annotation via mutex_lock_nested(). Signed-off-by: Mark Fasheh diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c index 8a3b6a1..452cfd1 100644 --- a/fs/configfs/dir.c +++ b/fs/configfs/dir.c @@ -1176,8 +1176,9 @@ void configfs_unregister_subsystem(struc return; } - mutex_lock(&configfs_sb->s_root->d_inode->i_mutex); - mutex_lock(&dentry->d_inode->i_mutex); + mutex_lock_nested(&configfs_sb->s_root->d_inode->i_mutex, + I_MUTEX_PARENT); + mutex_lock_nested(&dentry->d_inode->i_mutex, I_MUTEX_CHILD); if (configfs_detach_prep(dentry)) { printk(KERN_ERR "configfs: Tried to unregister non-empty subsystem!\n"); }