Hi All,
With the latest Linus tree as of this morning, I'm getting the warning
below continuously. I've attached the first two instances of it. The
machine is a Dell XPS 8300 with a BCM4313 wireless chip in it.
Userspace is Fedora 17 and NetworkManager is controlling things though I
don't have it set to connect to any networks.
Please let me know if you've seen this before and if there is more
information I can provide.
josh
[ 15.587855] brcmsmac bcma0:0: mfg 4bf core 812 rev 24 class 0 irq 16
[ 15.636460] cfg80211: World regulatory domain updated:
[ 15.636462] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 15.636463] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 15.636465] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 15.636466] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 15.636467] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 15.636468] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 15.703640] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 15.957344] ALSA sound/pci/hda/hda_intel.c:2745 Using COMBO position fix
[ 15.957532] snd_hda_intel 0000:00:1b.0: irq 46 for MSI/MSI-X
[ 16.253325] cfg80211: Calling CRDA for country: US
[ 16.271042] cfg80211: Regulatory domain changed to country: US
[ 16.271045] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 16.271048] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 16.271051] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[ 16.271053] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 16.271055] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 16.271057] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 16.271060] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
<snip a bunch of ALSA/input stuff>
[ 21.762086] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 25.698788] Bridge firewalling registered
[ 25.746690] device virbr0-nic entered promiscuous mode
[ 26.573028] ------------[ cut here ]------------
[ 26.573042] WARNING: at net/wireless/core.h:125 assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]()
[ 26.573045] Hardware name: XPS 8300
[ 26.573046] Modules linked in: xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack ib_iser rdma_cm ib_addr ip6table_filter tpm_bios ip6_tables iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel arc4 brcmsmac snd_hda_codec cordic brcmutil snd_hwdep mac80211 snd_pcm snd_page_alloc snd_timer cfg80211 snd coretemp rfkill serio_raw i2c_i801 soundcore lpc_ich bcma dcdbas microcode mfd_core mei vhost_net tun macvtap macvlan kvm_intel nfsd kvm auth_rpcgss nfs_acl lockd uinput crc32c_intel ghash_clmulni_intel broadcom tg3 usb_storage uas radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core sunrpc be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi
[ 26.573143] Pid: 757, comm: NetworkManager Not tainted 3.6.0-0.rc0.git8.1.fc18.x86_64 #1
[ 26.573145] Call Trace:
[ 26.573153] [<ffffffff8106782f>] warn_slowpath_common+0x7f/0xc0
[ 26.573159] [<ffffffff8106788a>] warn_slowpath_null+0x1a/0x20
[ 26.573170] [<ffffffffa04c730d>] assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]
[ 26.573181] [<ffffffffa04a8dcb>] freq_reg_info+0x6b/0x80 [cfg80211]
[ 26.573193] [<ffffffffa06b6c99>] brcms_c_channel_set_chanspec+0x2c9/0x350 [brcmsmac]
[ 26.573204] [<ffffffffa06b7330>] brcms_c_set_phy_chanspec+0x30/0x70 [brcmsmac]
[ 26.573216] [<ffffffffa06c1a45>] brcms_c_init+0xb25/0x12f0 [brcmsmac]
[ 26.573225] [<ffffffffa047e61c>] ? bcma_host_pci_write32+0x3c/0x50 [bcma]
[ 26.573235] [<ffffffffa06b322c>] brcms_init+0x5c/0x70 [brcmsmac]
[ 26.573247] [<ffffffffa06bff5e>] brcms_c_up+0x23e/0x520 [brcmsmac]
[ 26.573290] [<ffffffffa06b34a9>] brcms_up+0x29/0x30 [brcmsmac]
[ 26.573299] [<ffffffffa06b3d0d>] brcms_ops_start+0x6d/0xe0 [brcmsmac]
[ 26.573324] [<ffffffffa0626a01>] ieee80211_do_open+0x2e1/0x11b0 [mac80211]
[ 26.573342] [<ffffffffa062793d>] ieee80211_open+0x6d/0x80 [mac80211]
[ 26.573349] [<ffffffff8158fecf>] __dev_open+0x8f/0xf0
[ 26.573357] [<ffffffff81590191>] __dev_change_flags+0xa1/0x180
[ 26.573363] [<ffffffff81590328>] dev_change_flags+0x28/0x70
[ 26.573371] [<ffffffff8159e278>] do_setlink+0x378/0xa00
[ 26.573380] [<ffffffff810ac5a5>] ? sched_clock_cpu+0xc5/0x120
[ 26.573386] [<ffffffff81021db3>] ? native_sched_clock+0x13/0x80
[ 26.573392] [<ffffffff81359a51>] ? nla_parse+0x31/0xe0
[ 26.573398] [<ffffffff815a09ae>] rtnl_newlink+0x37e/0x560
[ 26.573407] [<ffffffff812d54a9>] ? selinux_capable+0x39/0x50
[ 26.573412] [<ffffffff812d1a58>] ? security_capable+0x18/0x20
[ 26.573418] [<ffffffff815a01d4>] rtnetlink_rcv_msg+0x114/0x2f0
[ 26.573424] [<ffffffff8159d047>] ? rtnl_lock+0x17/0x20
[ 26.573431] [<ffffffff8159d047>] ? rtnl_lock+0x17/0x20
[ 26.573440] [<ffffffff815a00c0>] ? __rtnl_unlock+0x20/0x20
[ 26.573447] [<ffffffff815bbf11>] netlink_rcv_skb+0xa1/0xb0
[ 26.573454] [<ffffffff8159d075>] rtnetlink_rcv+0x25/0x40
[ 26.573460] [<ffffffff815bb89d>] netlink_unicast+0x19d/0x220
[ 26.573466] [<ffffffff815bbbfb>] netlink_sendmsg+0x2db/0x360
[ 26.573474] [<ffffffff81576268>] ? sock_update_classid+0x148/0x2e0
[ 26.573480] [<ffffffff8156fd7c>] sock_sendmsg+0xbc/0xf0
[ 26.573487] [<ffffffff810ac66f>] ? local_clock+0x6f/0x80
[ 26.573495] [<ffffffff810d5a17>] ? lock_release_non_nested+0x2f7/0x330
[ 26.573501] [<ffffffff81570dec>] __sys_sendmsg+0x3ac/0x3c0
[ 26.573504] [<ffffffff81021db3>] ? native_sched_clock+0x13/0x80
[ 26.573508] [<ffffffff81021e29>] ? sched_clock+0x9/0x10
[ 26.573511] [<ffffffff810ac5a5>] ? sched_clock_cpu+0xc5/0x120
[ 26.573515] [<ffffffff810d05ad>] ? trace_hardirqs_off+0xd/0x10
[ 26.573519] [<ffffffff810ac66f>] ? local_clock+0x6f/0x80
[ 26.573523] [<ffffffff811c6939>] ? fget_light+0xf9/0x520
[ 26.573526] [<ffffffff811c687c>] ? fget_light+0x3c/0x520
[ 26.573530] [<ffffffff815737d9>] sys_sendmsg+0x49/0x90
[ 26.573537] [<ffffffff816d8429>] system_call_fastpath+0x16/0x1b
[ 26.573541] ---[ end trace 9edc8e6bb8e18f3f ]---
[ 26.575489] ieee80211 phy0: brcms_ops_bss_info_changed: qos enabled: false (implement)
[ 26.575571] ieee80211 phy0: brcms_ops_config: change power-save mode: false (implement)
[ 26.576055] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 26.729219] tg3 0000:03:00.0: irq 48 for MSI/MSI-X
[ 26.746776] IPv6: ADDRCONF(NETDEV_UP): p3p1: link is not ready
[ 27.084202] tg3 0000:03:00.0: p3p1: Link is down
[ 27.089383] IPv6: ADDRCONF(NETDEV_UP): virbr0: link is not ready
[ 28.413963] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 28.430879] NFSD: starting 90-second grace period
[ 28.666424] ------------[ cut here ]------------
[ 28.666441] WARNING: at net/wireless/core.h:125 assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]()
[ 28.666451] Hardware name: XPS 8300
[ 28.666451] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack ib_iser rdma_cm ib_addr ip6table_filter tpm_bios ip6_tables iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel arc4 brcmsmac snd_hda_codec cordic brcmutil snd_hwdep mac80211 snd_pcm snd_page_alloc snd_timer cfg80211 snd coretemp rfkill serio_raw i2c_i801 soundcore lpc_ich bcma dcdbas microcode mfd_core mei vhost_net tun macvtap macvlan kvm_intel nfsd kvm auth_rpcgss nfs_acl lockd uinput crc32c_intel ghash_clmulni_intel broadcom tg3 usb_storage uas radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core sunrpc be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi
[ 28.666504] Pid: 109, comm: kworker/u:5 Tainted: G W 3.6.0-0.rc0.git8.1.fc18.x86_64 #1
[ 28.666505] Call Trace:
[ 28.666510] [<ffffffff8106782f>] warn_slowpath_common+0x7f/0xc0
[ 28.666514] [<ffffffff8106788a>] warn_slowpath_null+0x1a/0x20
[ 28.666519] [<ffffffffa04c730d>] assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]
[ 28.666525] [<ffffffffa04a8dcb>] freq_reg_info+0x6b/0x80 [cfg80211]
[ 28.666531] [<ffffffffa06b6c99>] brcms_c_channel_set_chanspec+0x2c9/0x350 [brcmsmac]
[ 28.666537] [<ffffffffa06b7330>] brcms_c_set_phy_chanspec+0x30/0x70 [brcmsmac]
[ 28.666542] [<ffffffffa06baf71>] brcms_c_set_chanspec+0xa1/0x1d0 [brcmsmac]
[ 28.666548] [<ffffffffa06bcb1e>] brcms_c_set_channel+0x11e/0x140 [brcmsmac]
[ 28.666552] [<ffffffffa06b23c8>] brcms_ops_config+0x108/0x1f0 [brcmsmac]
[ 28.666563] [<ffffffffa060ed92>] ieee80211_hw_config+0x142/0x3f0 [mac80211]
[ 28.666572] [<ffffffffa0619f5f>] ieee80211_scan_work+0x21f/0x7b0 [mac80211]
[ 28.666576] [<ffffffff8108bdef>] process_one_work+0x20f/0x760
[ 28.666578] [<ffffffff8108bd87>] ? process_one_work+0x1a7/0x760
[ 28.666580] [<ffffffff8108c7ce>] ? worker_thread+0x21e/0x450
[ 28.666587] [<ffffffffa0619d40>] ? ieee80211_run_deferred_scan+0x120/0x120 [mac80211]
[ 28.666592] [<ffffffff8108c70e>] worker_thread+0x15e/0x450
[ 28.666595] [<ffffffff8108c5b0>] ? rescuer_thread+0x230/0x230
[ 28.666597] [<ffffffff81092527>] kthread+0xb7/0xc0
[ 28.666600] [<ffffffff816d9604>] kernel_thread_helper+0x4/0x10
[ 28.666603] [<ffffffff816cf970>] ? retint_restore_args+0x13/0x13
[ 28.666605] [<ffffffff81092470>] ? __init_kthread_worker+0x70/0x70
[ 28.666607] [<ffffffff816d9600>] ? gs_change+0x13/0x13
[ 28.666608] ---[ end trace 9edc8e6bb8e18f40 ]---
On 08/01/2012 05:38 PM, Arend van Spriel wrote:
>> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
>> >
>> > It looks like those calls were added in mid-June.
>> >
> I think mid-june sounds about right. We never observed the warning when
> changes to use regulatory infrastructure were tested/reviewed. Should
> this precondition be mentioned in cfg80211.h?
>
> Gr. AvS
Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
another solution is needed.
Gr. AvS
On Wed, Aug 01, 2012 at 07:14:45PM +0200, Johannes Berg wrote:
> On Wed, 2012-08-01 at 11:19 -0500, Seth Forshee wrote:
> > On Wed, Aug 01, 2012 at 05:53:58PM +0200, Johannes Berg wrote:
> > > On Wed, 2012-08-01 at 17:51 +0200, Arend van Spriel wrote:
> > > > On 08/01/2012 05:38 PM, Arend van Spriel wrote:
> > > > >> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
> > > > >> >
> > > > >> > It looks like those calls were added in mid-June.
> > > > >> >
> > > > > I think mid-june sounds about right. We never observed the warning when
> > > > > changes to use regulatory infrastructure were tested/reviewed. Should
> > > > > this precondition be mentioned in cfg80211.h?
> > > > >
> > > > > Gr. AvS
> > > >
> > > > Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
> > > > another solution is needed.
> > >
> > > Yeah I was going to say -- how can it possibly access that? It seems
> > > that in some patch the API got broken, it should be taking the lock or
> > > whatever ... I'll leave it to Luis to sort out though :-P
> >
> > In other drivers freq_reg_info only seems to get used by the regulatory
> > notifiers, which get called with the lock held. brcmsmac is wanting to
> > know whether or not OFDM is allowed when setting the channel though, and
> > I didn't find that information anywhere outside the regulatory
> > information. If there's another way then calling freq_reg_info() could
> > be avoided. Or maybe we could add an OFDM flag to the channel
> > information?
>
> Seems reasonable to add the flags (or some of them) to the channel
> flags, yeah.
Great, I'll work something up.
Seth
On 08/01/2012 05:52 PM, John W. Linville wrote:
> On Wed, Aug 01, 2012 at 05:51:08PM +0200, Arend van Spriel wrote:
>> On 08/01/2012 05:38 PM, Arend van Spriel wrote:
>>>> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
>>>>>
>>>>> It looks like those calls were added in mid-June.
>>>>>
>>> I think mid-june sounds about right. We never observed the warning when
>>> changes to use regulatory infrastructure were tested/reviewed. Should
>>> this precondition be mentioned in cfg80211.h?
>>>
>>> Gr. AvS
>>
>> Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
>> another solution is needed.
>
> Do we need to revert those patches?
>
either that or fix it.
Gr. AvS
On Wed, 2012-08-01 at 17:51 +0200, Arend van Spriel wrote:
> On 08/01/2012 05:38 PM, Arend van Spriel wrote:
> >> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
> >> >
> >> > It looks like those calls were added in mid-June.
> >> >
> > I think mid-june sounds about right. We never observed the warning when
> > changes to use regulatory infrastructure were tested/reviewed. Should
> > this precondition be mentioned in cfg80211.h?
> >
> > Gr. AvS
>
> Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
> another solution is needed.
Yeah I was going to say -- how can it possibly access that? It seems
that in some patch the API got broken, it should be taking the lock or
whatever ... I'll leave it to Luis to sort out though :-P
johannes
On Wed, Aug 01, 2012 at 05:51:08PM +0200, Arend van Spriel wrote:
> On 08/01/2012 05:38 PM, Arend van Spriel wrote:
> >> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
> >> >
> >> > It looks like those calls were added in mid-June.
> >> >
> > I think mid-june sounds about right. We never observed the warning when
> > changes to use regulatory infrastructure were tested/reviewed. Should
> > this precondition be mentioned in cfg80211.h?
> >
> > Gr. AvS
>
> Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
> another solution is needed.
Do we need to revert those patches?
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, 2012-08-01 at 11:19 -0500, Seth Forshee wrote:
> On Wed, Aug 01, 2012 at 05:53:58PM +0200, Johannes Berg wrote:
> > On Wed, 2012-08-01 at 17:51 +0200, Arend van Spriel wrote:
> > > On 08/01/2012 05:38 PM, Arend van Spriel wrote:
> > > >> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
> > > >> >
> > > >> > It looks like those calls were added in mid-June.
> > > >> >
> > > > I think mid-june sounds about right. We never observed the warning when
> > > > changes to use regulatory infrastructure were tested/reviewed. Should
> > > > this precondition be mentioned in cfg80211.h?
> > > >
> > > > Gr. AvS
> > >
> > > Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
> > > another solution is needed.
> >
> > Yeah I was going to say -- how can it possibly access that? It seems
> > that in some patch the API got broken, it should be taking the lock or
> > whatever ... I'll leave it to Luis to sort out though :-P
>
> In other drivers freq_reg_info only seems to get used by the regulatory
> notifiers, which get called with the lock held. brcmsmac is wanting to
> know whether or not OFDM is allowed when setting the channel though, and
> I didn't find that information anywhere outside the regulatory
> information. If there's another way then calling freq_reg_info() could
> be avoided. Or maybe we could add an OFDM flag to the channel
> information?
Seems reasonable to add the flags (or some of them) to the channel
flags, yeah.
johannes
On 08/01/2012 04:18 PM, John W. Linville wrote:
> On Wed, Aug 01, 2012 at 09:12:33AM -0400, Josh Boyer wrote:
>
>> > [ 26.573028] ------------[ cut here ]------------
>> > [ 26.573042] WARNING: at net/wireless/core.h:125 assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]()
>> > [ 26.573045] Hardware name: XPS 8300
>> > [ 26.573046] Modules linked in: xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack ib_iser rdma_cm ib_addr ip6table_filter tpm_bios ip6_tables iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel arc4 brcmsmac snd_hda_codec cordic brcmutil snd_hwdep mac80211 snd_pcm snd_page_alloc snd_timer cfg80211 snd coretemp rfkill serio_raw i2c_i801 soundcore lpc_ich bcma dcdbas microcode mfd_core mei vhost_net tun macvtap macvlan kvm_intel nfsd kvm auth_rpcgss nfs_acl lockd uinput crc32c_intel ghash_clmulni_intel broadcom tg3 usb_storage uas radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core sunrpc be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi
>> > [ 26.573143] Pid: 757, comm: NetworkManager Not tainted 3.6.0-0.rc0.git8.1.fc18.x86_64 #1
>> > [ 26.573145] Call Trace:
>> > [ 26.573153] [<ffffffff8106782f>] warn_slowpath_common+0x7f/0xc0
>> > [ 26.573159] [<ffffffff8106788a>] warn_slowpath_null+0x1a/0x20
>> > [ 26.573170] [<ffffffffa04c730d>] assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]
>> > [ 26.573181] [<ffffffffa04a8dcb>] freq_reg_info+0x6b/0x80 [cfg80211]
> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
>
> It looks like those calls were added in mid-June.
>
I think mid-june sounds about right. We never observed the warning when
changes to use regulatory infrastructure were tested/reviewed. Should
this precondition be mentioned in cfg80211.h?
Gr. AvS
On Wed, Aug 01, 2012 at 09:12:33AM -0400, Josh Boyer wrote:
> <snip a bunch of ALSA/input stuff>
>
> [ 21.762086] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> [ 25.698788] Bridge firewalling registered
> [ 25.746690] device virbr0-nic entered promiscuous mode
> [ 26.573028] ------------[ cut here ]------------
> [ 26.573042] WARNING: at net/wireless/core.h:125 assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]()
> [ 26.573045] Hardware name: XPS 8300
> [ 26.573046] Modules linked in: xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack ib_iser rdma_cm ib_addr ip6table_filter tpm_bios ip6_tables iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel arc4 brcmsmac snd_hda_codec cordic brcmutil snd_hwdep mac80211 snd_pcm snd_page_alloc snd_timer cfg80211 snd coretemp rfkill serio_raw i2c_i801 soundcore lpc_ich bcma dcdbas microcode mfd_core mei vhost_net tun macvtap macvlan kvm_intel nfsd kvm auth_rpcgss nfs_acl lockd uinput crc32c_intel ghash_clmulni_intel broadcom tg3 usb_storage uas radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core sunrpc be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi
> [ 26.573143] Pid: 757, comm: NetworkManager Not tainted 3.6.0-0.rc0.git8.1.fc18.x86_64 #1
> [ 26.573145] Call Trace:
> [ 26.573153] [<ffffffff8106782f>] warn_slowpath_common+0x7f/0xc0
> [ 26.573159] [<ffffffff8106788a>] warn_slowpath_null+0x1a/0x20
> [ 26.573170] [<ffffffffa04c730d>] assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]
> [ 26.573181] [<ffffffffa04a8dcb>] freq_reg_info+0x6b/0x80 [cfg80211]
brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
It looks like those calls were added in mid-June.
> [ 26.573193] [<ffffffffa06b6c99>] brcms_c_channel_set_chanspec+0x2c9/0x350 [brcmsmac]
> [ 26.573204] [<ffffffffa06b7330>] brcms_c_set_phy_chanspec+0x30/0x70 [brcmsmac]
> [ 26.573216] [<ffffffffa06c1a45>] brcms_c_init+0xb25/0x12f0 [brcmsmac]
> [ 26.573225] [<ffffffffa047e61c>] ? bcma_host_pci_write32+0x3c/0x50 [bcma]
> [ 26.573235] [<ffffffffa06b322c>] brcms_init+0x5c/0x70 [brcmsmac]
> [ 26.573247] [<ffffffffa06bff5e>] brcms_c_up+0x23e/0x520 [brcmsmac]
> [ 26.573290] [<ffffffffa06b34a9>] brcms_up+0x29/0x30 [brcmsmac]
> [ 26.573299] [<ffffffffa06b3d0d>] brcms_ops_start+0x6d/0xe0 [brcmsmac]
> [ 26.573324] [<ffffffffa0626a01>] ieee80211_do_open+0x2e1/0x11b0 [mac80211]
> [ 26.573342] [<ffffffffa062793d>] ieee80211_open+0x6d/0x80 [mac80211]
> [ 26.573349] [<ffffffff8158fecf>] __dev_open+0x8f/0xf0
> [ 26.573357] [<ffffffff81590191>] __dev_change_flags+0xa1/0x180
> [ 26.573363] [<ffffffff81590328>] dev_change_flags+0x28/0x70
> [ 26.573371] [<ffffffff8159e278>] do_setlink+0x378/0xa00
> [ 26.573380] [<ffffffff810ac5a5>] ? sched_clock_cpu+0xc5/0x120
> [ 26.573386] [<ffffffff81021db3>] ? native_sched_clock+0x13/0x80
> [ 26.573392] [<ffffffff81359a51>] ? nla_parse+0x31/0xe0
> [ 26.573398] [<ffffffff815a09ae>] rtnl_newlink+0x37e/0x560
> [ 26.573407] [<ffffffff812d54a9>] ? selinux_capable+0x39/0x50
> [ 26.573412] [<ffffffff812d1a58>] ? security_capable+0x18/0x20
> [ 26.573418] [<ffffffff815a01d4>] rtnetlink_rcv_msg+0x114/0x2f0
> [ 26.573424] [<ffffffff8159d047>] ? rtnl_lock+0x17/0x20
> [ 26.573431] [<ffffffff8159d047>] ? rtnl_lock+0x17/0x20
> [ 26.573440] [<ffffffff815a00c0>] ? __rtnl_unlock+0x20/0x20
> [ 26.573447] [<ffffffff815bbf11>] netlink_rcv_skb+0xa1/0xb0
> [ 26.573454] [<ffffffff8159d075>] rtnetlink_rcv+0x25/0x40
> [ 26.573460] [<ffffffff815bb89d>] netlink_unicast+0x19d/0x220
> [ 26.573466] [<ffffffff815bbbfb>] netlink_sendmsg+0x2db/0x360
> [ 26.573474] [<ffffffff81576268>] ? sock_update_classid+0x148/0x2e0
> [ 26.573480] [<ffffffff8156fd7c>] sock_sendmsg+0xbc/0xf0
> [ 26.573487] [<ffffffff810ac66f>] ? local_clock+0x6f/0x80
> [ 26.573495] [<ffffffff810d5a17>] ? lock_release_non_nested+0x2f7/0x330
> [ 26.573501] [<ffffffff81570dec>] __sys_sendmsg+0x3ac/0x3c0
> [ 26.573504] [<ffffffff81021db3>] ? native_sched_clock+0x13/0x80
> [ 26.573508] [<ffffffff81021e29>] ? sched_clock+0x9/0x10
> [ 26.573511] [<ffffffff810ac5a5>] ? sched_clock_cpu+0xc5/0x120
> [ 26.573515] [<ffffffff810d05ad>] ? trace_hardirqs_off+0xd/0x10
> [ 26.573519] [<ffffffff810ac66f>] ? local_clock+0x6f/0x80
> [ 26.573523] [<ffffffff811c6939>] ? fget_light+0xf9/0x520
> [ 26.573526] [<ffffffff811c687c>] ? fget_light+0x3c/0x520
> [ 26.573530] [<ffffffff815737d9>] sys_sendmsg+0x49/0x90
> [ 26.573537] [<ffffffff816d8429>] system_call_fastpath+0x16/0x1b
> [ 26.573541] ---[ end trace 9edc8e6bb8e18f3f ]---
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, Aug 01, 2012 at 05:53:58PM +0200, Johannes Berg wrote:
> On Wed, 2012-08-01 at 17:51 +0200, Arend van Spriel wrote:
> > On 08/01/2012 05:38 PM, Arend van Spriel wrote:
> > >> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
> > >> >
> > >> > It looks like those calls were added in mid-June.
> > >> >
> > > I think mid-june sounds about right. We never observed the warning when
> > > changes to use regulatory infrastructure were tested/reviewed. Should
> > > this precondition be mentioned in cfg80211.h?
> > >
> > > Gr. AvS
> >
> > Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
> > another solution is needed.
>
> Yeah I was going to say -- how can it possibly access that? It seems
> that in some patch the API got broken, it should be taking the lock or
> whatever ... I'll leave it to Luis to sort out though :-P
In other drivers freq_reg_info only seems to get used by the regulatory
notifiers, which get called with the lock held. brcmsmac is wanting to
know whether or not OFDM is allowed when setting the channel though, and
I didn't find that information anywhere outside the regulatory
information. If there's another way then calling freq_reg_info() could
be avoided. Or maybe we could add an OFDM flag to the channel
information?
Seth
+ Luis
On 08/01/2012 05:53 PM, Johannes Berg wrote:
> On Wed, 2012-08-01 at 17:51 +0200, Arend van Spriel wrote:
>> On 08/01/2012 05:38 PM, Arend van Spriel wrote:
>>>> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
>>>>>
>>>>> It looks like those calls were added in mid-June.
>>>>>
>>> I think mid-june sounds about right. We never observed the warning when
>>> changes to use regulatory infrastructure were tested/reviewed. Should
>>> this precondition be mentioned in cfg80211.h?
>>>
>>> Gr. AvS
>>
>> Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
>> another solution is needed.
>
> Yeah I was going to say -- how can it possibly access that? It seems
> that in some patch the API got broken, it should be taking the lock or
> whatever ... I'll leave it to Luis to sort out though :-P
>
> johannes
>
The assert was added by following commit:
commit ac46d48e00349c63650b3cc6f9460fcc183da6a6
Author: Luis R. Rodriguez <[email protected]>
Date: Fri May 1 18:44:50 2009 -0400
cfg80211: fix race condition with wiphy_apply_custom_regulatory()
We forgot to lock using the cfg80211_mutex in
wiphy_apply_custom_regulatory(). Without the lock
there is possible race between processing a reply from CRDA
and a driver calling wiphy_apply_custom_regulatory(). During
the processing of the reply from CRDA we free last_request and
wiphy_apply_custom_regulatory() eventually accesses an
element from last_request in the through freq_reg_info_regd().
This is very difficult to reproduce (I haven't), it takes us
3 hours and you need to be banging hard, but the race is obvious
by looking at the code.
This should only affect those who use this caller, which currently
is ath5k, ath9k, and ar9170.
EIP: 0060:[<f8ebec50>] EFLAGS: 00210282 CPU: 1
EIP is at freq_reg_info_regd+0x24/0x121 [cfg80211]
It seems the API was as it currently is when adding regulatory framework
changes in brcmsmac so we should have seen this assert flying by. The
problem is that freq_reg_info() is exposed in cfg80211.h, but as it is
now it can only be used under the cfg80211_mutex lock, ie. in regulatory
notify callback (as Seth indicated).
Gr. AvS
On 08/01/2012 07:24 PM, Arend van Spriel wrote:
> It seems the API was as it currently is when adding regulatory framework
> changes in brcmsmac so we should have seen this assert flying by. The
> problem is that freq_reg_info() is exposed in cfg80211.h, but as it is
> now it can only be used under the cfg80211_mutex lock, ie. in regulatory
> notify callback (as Seth indicated).
>
> Gr. AvS
Ah, I see you need to run a LOCKDEP-enabled kernel to get this warning.
Gr. AvS