Bug 67561

Summary: possible circular locking dependency, b43
Product: Networking Reporter: yury (urykhy)
Component: WirelessAssignee: networking_wireless (networking_wireless)
Status: CLOSED CODE_FIX    
Severity: normal CC: andrey.vihrov, Larry.Finger, linville, zajec5
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 3.12 Subsystem:
Regression: No Bisected commit-id:
Attachments: Patch to change locking order

Description yury 2013-12-23 17:13:57 UTC 
======================================================
[ 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
Comment 1 Larry Finger 2014-01-06 22:31:55 UTC 
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?
Comment 2 yury 2014-01-07 09:19:20 UTC 
Debian stable, no nm.

i use hostapd for wifi ap and rfkill to enable/disable wireless.
Comment 3 Larry Finger 2014-01-09 18:51:07 UTC 
Created attachment 121401 [details]
Patch to change locking order

Please try this patch to see if it fixes the problem.
Comment 4 yury 2014-01-11 11:33:39 UTC 
i make few suspend/resume cycles, and found no problem.
Comment 5 Rafał Miłecki 2014-11-19 09:39:57 UTC 
Larry: will you (rebase &) submit your patch, please?
Comment 6 Larry Finger 2014-11-19 15:53:48 UTC 
I had completely forgotten this whole issue. I will submit that patch.
Comment 7 Larry Finger 2014-11-19 16:02:58 UTC 
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.