From: Srinivasa Ds <srinivasa@in.ibm.com>
To: linux-kernel@vger.kernel.org, mingo@elte.hu
Subject: Issues with possible recursive locking
Date: Wed, 18 Oct 2006 09:37:58 +0530 [thread overview]
Message-ID: <4535A89E.9070609@in.ibm.com> (raw)
When I was removing dlm module,I hit in to below error.
==========================================
[ INFO: possible recursive locking detected ]
2.6.18#1
---------------------------------------------
modprobe/4501 is trying to acquire lock:
(&inode->i_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24
but task is already holding lock:
(&inode->i_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24
other info that might help us debug this:
1 lock held by modprobe/4501:
#0: (&inode->i_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24
stack backtrace:
[<c04051ed>] show_trace_log_lvl+0x58/0x16a
[<c04057fa>] show_trace+0xd/0x10
[<c0405913>] dump_stack+0x19/0x1b
[<c043b6f1>] __lock_acquire+0x778/0x99c
[<c043be86>] lock_acquire+0x4b/0x6d
[<c0611ceb>] __mutex_lock_slowpath+0xbc/0x20a
[<c0611e5a>] mutex_lock+0x21/0x24
[<f89c2562>] configfs_unregister_subsystem+0x3e/0xa8 [configfs]
[<f8f4263f>] dlm_config_exit+0xd/0xf [dlm]
[<f8f4db94>] exit_dlm+0x12/0x23 [dlm]
[<c0442790>] sys_delete_module+0x18d/0x1b5
[<c0403fb7>] syscall_call+0x7/0xb
===========================================================
Cause for this problem is, lock-validator validates the locks through
lock class. And by definition,a lock in struct inode considered as one
class, irrespective of number of of instances of different inode present
in the system.
Hence 2 consecutive mutex lock on d_inode->i_mutex considered as
recursive lock,eventhough both inodes are different. Thats what
happening below. Is it not a kernel design constraint ??
==============================================
void configfs_unregister_subsystem(struct configfs_subsystem *subsys)
{
struct config_group *group = &subsys->su_group;
struct dentry *dentry = group->cg_item.ci_dentry;
if (dentry->d_parent != configfs_sb->s_root) {
printk(KERN_ERR "configfs: Tried to unregister
non-subsystem!\n");
return;
}
mutex_lock(&configfs_sb->s_root->d_inode->i_mutex);
mutex_lock(&dentry->d_inode->i_mutex);
==> problem is here
if (configfs_detach_prep(dentry)) {
printk(KERN_ERR "configfs: Tried to unregister non-empty
subsystem!\n");
}
===========================================
next reply other threads:[~2006-10-18 3:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-18 4:07 Srinivasa Ds [this message]
2006-10-19 16:53 ` Issues with possible recursive locking Mark Fasheh
2006-10-25 6:39 ` Srinivasa Ds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4535A89E.9070609@in.ibm.com \
--to=srinivasa@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox