[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <453F06A1.6040101@in.ibm.com>
Date: Wed, 25 Oct 2006 12:09:29 +0530
From: Srinivasa Ds <srinivasa@...ibm.com>
To: Mark Fasheh <mark.fasheh@...cle.com>
CC: linux-kernel@...r.kernel.org, mingo@...e.hu,
Joel Becker <Joel.Becker@...cle.com>
Subject: Re: Issues with possible recursive locking
Mark Fasheh wrote:
> 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.
>
Thanks Mark,It worked fine for me.
> 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: [<c02ff984>] mutex_lock+0x21/0x24
>
> but task is already holding lock:
> (&inode->i_mutex){--..}, at: [<c02ff984>] 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: [<c0177194>] lookup_create+0x1d/0x73
> #1: (&inode->i_mutex){--..}, at: [<c02ff984>] mutex_lock+0x21/0x24
>
> stack backtrace:
> [<c0104d0a>] dump_trace+0x64/0x1c2
> [<c0104e7a>] show_trace_log_lvl+0x12/0x25
> [<c01053c6>] show_trace+0xd/0x10
> [<c01054dc>] dump_stack+0x19/0x1b
> [<c013c7bb>] __lock_acquire+0x6c6/0x8e3
> [<c013cf1b>] lock_acquire+0x4b/0x6c
> [<c02ff81d>] __mutex_lock_slowpath+0xb0/0x1f6
> [<c02ff984>] mutex_lock+0x21/0x24
> [<f8aa2800>] configfs_add_file+0x36/0x60 [configfs]
> [<f8aa285f>] configfs_create_file+0x35/0x38 [configfs]
> [<f8aa3260>] configfs_attach_item+0x13d/0x180 [configfs]
> [<f8aa32b7>] configfs_attach_group+0x14/0x154 [configfs]
> [<f8aa3377>] configfs_attach_group+0xd4/0x154 [configfs]
> [<f8aa3d8b>] configfs_mkdir+0x1b2/0x287 [configfs]
> [<c017666a>] vfs_mkdir+0xca/0x131
> [<c0178c8d>] sys_mkdirat+0x88/0xbb
> [<c0178cd0>] sys_mkdir+0x10/0x12
> [<c0103e2b>] 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 <mark.fasheh@...cle.com>
>
> 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");
> }
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists