Bug 472221 - configfs lockdep warning when starting dlm/cman
configfs lockdep warning when starting dlm/cman
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-19 08:53 EST by Jeff Layton
Modified: 2014-06-18 03:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-19 16:22:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Layton 2008-11-19 08:53:42 EST
I configured my rawhide xen guest as a single-node cluster and got the following messages in the ring buffer. This may actually be a problem in configfs:

Bridge firewalling registered
virbr0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
virbr0: starting userspace STP failed, starting kernel STP
SELinux: initialized (dev proc, type proc), uses genfs_contexts
Not cloning cgroup for unused subsystem ns
virbr0: no IPv6 routers present
SELinux: initialized (dev configfs, type configfs), uses genfs_contexts
DLM (built Nov 17 2008 03:44:49) installed
GFS2 (built Nov 17 2008 03:45:53) installed
Lock_DLM (built Nov 17 2008 03:46:04) installed

=============================================
[ INFO: possible recursive locking detected ]
2.6.27.5-113.fc10.x86_64.debug #1
---------------------------------------------
dlm_controld/2883 is trying to acquire lock:
 (&sb->s_type->i_mutex_key#11/2){--..}, at: [<ffffffffa00d1c4e>] configfs_attach_group+0x4a/0x183 [configfs]

but task is already holding lock:
 (&sb->s_type->i_mutex_key#11/2){--..}, at: [<ffffffffa00d1c4e>] configfs_attach_group+0x4a/0x183 [configfs]

other info that might help us debug this:
2 locks held by dlm_controld/2883:
 #0:  (&sb->s_type->i_mutex_key#10/1){--..}, at: [<ffffffff810d1525>] lookup_create+0x26/0x94
 #1:  (&sb->s_type->i_mutex_key#11/2){--..}, at: [<ffffffffa00d1c4e>] configfs_attach_group+0x4a/0x183 [configfs]

stack backtrace:
Pid: 2883, comm: dlm_controld Not tainted 2.6.27.5-113.fc10.x86_64.debug #1

Call Trace:
 [<ffffffff81064759>] __lock_acquire+0x82c/0xc06
 [<ffffffff81064bc0>] lock_acquire+0x8d/0xba
 [<ffffffffa00d1c4e>] ? configfs_attach_group+0x4a/0x183 [configfs]
 [<ffffffff8134ce3a>] __mutex_lock_common+0xed/0x35d
 [<ffffffffa00d1c4e>] ? configfs_attach_group+0x4a/0x183 [configfs]
 [<ffffffff8114762e>] ? security_d_instantiate+0x1f/0x21
 [<ffffffffa00d1c4e>] ? configfs_attach_group+0x4a/0x183 [configfs]
 [<ffffffff8134d153>] mutex_lock_nested+0x35/0x3a
 [<ffffffffa00d1c4e>] configfs_attach_group+0x4a/0x183 [configfs]
 [<ffffffff8134e5d3>] ? _spin_unlock+0x26/0x2a
 [<ffffffffa00d1cfe>] configfs_attach_group+0xfa/0x183 [configfs]
 [<ffffffffa00d1fbc>] configfs_mkdir+0x235/0x320 [configfs]
 [<ffffffff810d180e>] vfs_mkdir+0x72/0xc6
 [<ffffffff810d41de>] sys_mkdirat+0xa2/0xf5
 [<ffffffff8134e140>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff81063796>] ? trace_hardirqs_on_caller+0x10f/0x133
 [<ffffffff810d4244>] sys_mkdir+0x13/0x15
 [<ffffffff8101022a>] system_call_fastpath+0x16/0x1b
Comment 1 Dave Jones 2008-11-19 15:37:11 EST
You're probably best off taking this straight to upstream given we don't touch this code at all in the Fedora kernel.
Comment 2 Jeff Layton 2008-11-19 16:14:57 EST
Thanks Dave. I'll fire off an email to LKML with the trace...
Comment 3 Jeff Layton 2008-11-19 16:22:14 EST
Ahh, spoke with Joel Becker on IRC and he said that this is a known bug that he's planning to fix. I'll close this BZ...

Note You need to log in before you can comment on or make changes to this bug.