====================================================== [ INFO: possible circular locking dependency detected ] 3.12.0 #1 Not tainted ------------------------------------------------------- rfkill/10040 is trying to acquire lock: (rtnl_mutex){+.+.+.}, at: [<ffffffff8146f282>] rtnl_lock+0x12/0x20 but task is already holding lock: (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa04832ca>] rfkill_fop_write+0x6a/0x170 [rfkill] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (rfkill_global_mutex){+.+.+.}: [<ffffffff810ac2d5>] lock_acquire+0x95/0x110 [<ffffffff81531972>] mutex_lock_nested+0x52/0x3b0 [<ffffffffa048253a>] rfkill_fop_open+0x8a/0x1c0 [rfkill] [<ffffffff8138015f>] misc_open+0xaf/0x1c0 [<ffffffff81144da6>] chrdev_open+0x96/0x1c0 [<ffffffff8113e11e>] do_dentry_open.isra.17+0x1fe/0x290 [<ffffffff8113e299>] finish_open+0x19/0x30 [<ffffffff8114f11e>] do_last.isra.62+0x5ce/0xcf0 [<ffffffff8114f8fc>] path_openat+0xbc/0x670 [<ffffffff8115027e>] do_filp_open+0x3e/0xa0 [<ffffffff8113f48c>] do_sys_open+0x13c/0x230 [<ffffffff81190766>] compat_SyS_open+0x16/0x20 [<ffffffff81537b21>] sysenter_dispatch+0x7/0x23 -> #3 (misc_mtx){+.+.+.}: [<ffffffff810ac2d5>] lock_acquire+0x95/0x110 [<ffffffff81531972>] mutex_lock_nested+0x52/0x3b0 [<ffffffff81380434>] misc_register+0x24/0x130 [<ffffffffa04be6d9>] hwrng_register+0x109/0x1c4 [rng_core] [<ffffffffa0600fb8>] b43_wireless_core_init+0xd48/0x1140 [b43] [<ffffffffa0601ab8>] b43_op_start+0x1a8/0x1d0 [b43] [<ffffffffa05782a2>] ieee80211_do_open+0x372/0xdd0 [mac80211] [<ffffffffa0578d61>] ieee80211_open+0x61/0x70 [mac80211] [<ffffffff814622c7>] __dev_open+0x87/0xf0 [<ffffffff8146257c>] __dev_change_flags+0x9c/0x180 [<ffffffff81462713>] dev_change_flags+0x23/0x70 [<ffffffff814c8f43>] devinet_ioctl+0x5c3/0x680 [<ffffffff814ca03c>] inet_ioctl+0x7c/0xa0 [<ffffffff81446ffb>] sock_do_ioctl+0x2b/0x70 [<ffffffff814486dd>] compat_sock_ioctl+0x6dd/0xb60 [<ffffffff81191047>] compat_sys_ioctl+0x97/0x14c0 [<ffffffff81537b21>] sysenter_dispatch+0x7/0x23 -> #2 (rng_mutex){+.+.+.}: [<ffffffff810ac2d5>] lock_acquire+0x95/0x110 [<ffffffff81531972>] mutex_lock_nested+0x52/0x3b0 [<ffffffffa04be5ff>] hwrng_register+0x2f/0x1c4 [rng_core] [<ffffffffa0600fb8>] b43_wireless_core_init+0xd48/0x1140 [b43] [<ffffffffa0601ab8>] b43_op_start+0x1a8/0x1d0 [b43] [<ffffffffa05782a2>] ieee80211_do_open+0x372/0xdd0 [mac80211] [<ffffffffa0578d61>] ieee80211_open+0x61/0x70 [mac80211] [<ffffffff814622c7>] __dev_open+0x87/0xf0 [<ffffffff8146257c>] __dev_change_flags+0x9c/0x180 [<ffffffff81462713>] dev_change_flags+0x23/0x70 [<ffffffff814c8f43>] devinet_ioctl+0x5c3/0x680 [<ffffffff814ca03c>] inet_ioctl+0x7c/0xa0 [<ffffffff81446ffb>] sock_do_ioctl+0x2b/0x70 [<ffffffff814486dd>] compat_sock_ioctl+0x6dd/0xb60 [<ffffffff81191047>] compat_sys_ioctl+0x97/0x14c0 [<ffffffff81537b21>] sysenter_dispatch+0x7/0x23 -> #1 (&wl->mutex){+.+.+.}: [<ffffffff810ac2d5>] lock_acquire+0x95/0x110 [<ffffffff81531972>] mutex_lock_nested+0x52/0x3b0 [<ffffffffa06019e7>] b43_op_start+0xd7/0x1d0 [b43] [<ffffffffa05782a2>] ieee80211_do_open+0x372/0xdd0 [mac80211] [<ffffffffa0578d61>] ieee80211_open+0x61/0x70 [mac80211] [<ffffffff814622c7>] __dev_open+0x87/0xf0 [<ffffffff8146257c>] __dev_change_flags+0x9c/0x180 [<ffffffff81462713>] dev_change_flags+0x23/0x70 [<ffffffff814c8f43>] devinet_ioctl+0x5c3/0x680 [<ffffffff814ca03c>] inet_ioctl+0x7c/0xa0 [<ffffffff81446ffb>] sock_do_ioctl+0x2b/0x70 [<ffffffff814486dd>] compat_sock_ioctl+0x6dd/0xb60 [<ffffffff81191047>] compat_sys_ioctl+0x97/0x14c0 [<ffffffff81537b21>] sysenter_dispatch+0x7/0x23 -> #0 (rtnl_mutex){+.+.+.}: [<ffffffff810ab998>] __lock_acquire+0x1b58/0x1e60 [<ffffffff810ac2d5>] lock_acquire+0x95/0x110 [<ffffffff81531972>] mutex_lock_nested+0x52/0x3b0 [<ffffffff8146f282>] rtnl_lock+0x12/0x20 [<ffffffffa04c47e8>] cfg80211_rfkill_set_block+0x28/0x90 [cfg80211] [<ffffffffa048307b>] rfkill_set_block+0x8b/0x130 [rfkill] [<ffffffffa0483337>] rfkill_fop_write+0xd7/0x170 [rfkill] [<ffffffff811406b3>] vfs_write+0xc3/0x1f0 [<ffffffff81140bd0>] SyS_write+0x50/0xb0 [<ffffffff81537b21>] sysenter_dispatch+0x7/0x23 other info that might help us debug this: Chain exists of: rtnl_mutex --> misc_mtx --> rfkill_global_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rfkill_global_mutex); lock(misc_mtx); lock(rfkill_global_mutex); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by rfkill/10040: #0: (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa04832ca>] rfkill_fop_write+0x6a/0x170 [rfkill] stack backtrace: CPU: 1 PID: 10040 Comm: rfkill Not tainted 3.12.0 #1 Hardware name: Hewlett-Packard HP ProBook 6550b/146D, BIOS 68CDE Ver. F.04 10/27/2010 ffffffff81f21950 ffff8801a884bc78 ffffffff8152db3a ffffffff81f18610 ffff8801a884bcb8 ffffffff8152a68a ffff8801a884bd28 00000000008fa26b 0000000000000001 ffff88009992a2a0 ffff88009992a9a8 ffff88009992a9e0 Call Trace: [<ffffffff8152db3a>] dump_stack+0x45/0x56 [<ffffffff8152a68a>] print_circular_bug+0x2ac/0x2bb [<ffffffff810ab998>] __lock_acquire+0x1b58/0x1e60 [<ffffffff810ac2d5>] lock_acquire+0x95/0x110 [<ffffffff8146f282>] ? rtnl_lock+0x12/0x20 [<ffffffff81531972>] mutex_lock_nested+0x52/0x3b0 [<ffffffff8146f282>] ? rtnl_lock+0x12/0x20 [<ffffffff8146f282>] ? rtnl_lock+0x12/0x20 [<ffffffff810acbcd>] ? mark_held_locks+0x9d/0x140 [<ffffffff8153548a>] ? _raw_spin_unlock_irqrestore+0x3a/0x70 [<ffffffff8146f282>] rtnl_lock+0x12/0x20 [<ffffffffa04c47e8>] cfg80211_rfkill_set_block+0x28/0x90 [cfg80211] [<ffffffffa048307b>] rfkill_set_block+0x8b/0x130 [rfkill] [<ffffffffa0483337>] rfkill_fop_write+0xd7/0x170 [rfkill] [<ffffffff811406b3>] vfs_write+0xc3/0x1f0 [<ffffffff81140bd0>] SyS_write+0x50/0xb0 [<ffffffff81537b21>] sysenter_dispatch+0x7/0x23 [<ffffffff812e5cae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
Unfortunately, I do not see this lockdep problem, and I do have lockdep testing turned on. My system is openSUSE 13.1 KDE and I control the wireless with NetworkManager. What are those details for your system?
Debian stable, no nm. i use hostapd for wifi ap and rfkill to enable/disable wireless.
Created attachment 121401 [details] Patch to change locking order Please try this patch to see if it fixes the problem.
i make few suspend/resume cycles, and found no problem.
Larry: will you (rebase &) submit your patch, please?
I had completely forgotten this whole issue. I will submit that patch.
The reason I forgot about it is that the patch was accepted into the kernel on Jan. 12 as commit 0916404. I just forgot to change the bug status.
OK, that's right. Thanks. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=09164043f63c947a49797750a09ca1cd7c31108e