All of lore.kernel.org
 help / color / mirror / Atom feed
* hashing error in hacked 4.4.6+ kernel.
@ 2016-03-26  0:56 Ben Greear
  2016-03-26 19:20 ` Johannes Berg
  0 siblings, 1 reply; 4+ messages in thread
From: Ben Greear @ 2016-03-26  0:56 UTC (permalink / raw)
  To: linux-wireless

First, this kernel has lots of patches, including patches to the station hashing.

http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary

But, my hashing patches cannot cause an error return as far as I can tell,
so I'm not sure this is my bug or not.

And, I'm running custom wave-2 ath10k firmware with 35 or so station
vdevs doing encryption, and with a lot of ath10k patches from newer
development kernels....


Test case was to bring up the stations.  All but one (sta28) came up fine.

Seems it had issues on the initial connect for one reason or another, and then
on deauth, removing from the has failed (sta_info_hash_del).


I'm curious if anyone has seen anything similar lately?


Splat is below...narrative continues after...


Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28: deauthenticating from 04:f0:21:f6:85:1c by local choice (Reason: 3=DEAUTH_LEAVING)
Mar 25 17:02:05 ath10k.candelatech.com kernel: ------------[ cut here ]------------
Mar 25 17:02:05 ath10k.candelatech.com kernel: WARNING: CPU: 2 PID: 6227 at /home/greearb/git/linux-4.4.dev.y/net/mac80211/sta_info.c:921 
__sta_info_destroy_part1+0x91/0x422 [mac80211]()
Mar 25 17:02:05 ath10k.candelatech.com kernel: Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv4 8021q garp mrp stp llc bnep 
bluetooth fuse macvlan wanlink(O) pktgen rpcsec_gss_krb5 nfsv4 nfs fscache iTCO_wdt iTCO_vendor_support coretemp hwmon ath9k intel_rapl iosf_mbi ath10k_pci 
ath9k_common ath10k_core ath9k_hw x86_pkg_temp_thermal intel_powerclamp kvm_intel ath kvm mac80211 joydev irqbypass serio_raw snd_hda_codec_hdmi pcspkr 
snd_hda_codec_realtek cfg80211 snd_hda_codec_generic i2c_i801 lpc_ich snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm 
8250_fintek snd_timer snd shpchp soundcore tpm_tis tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc ata_generic pata_acpi i915 i2c_algo_bit drm_kms_helper e1000e 
ptp pps_core drm i2c_core fjes video ipv6 [last unloaded: nf_conntrack]
Mar 25 17:02:05 ath10k.candelatech.com kernel:
Mar 25 17:02:05 ath10k.candelatech.com kernel: CPU: 2 PID: 6227 Comm: ip Tainted: G        W  O    4.4.6+ #21
Mar 25 17:02:05 ath10k.candelatech.com kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./HURONRIVER, BIOS 4.6.5 05/02/2012
Mar 25 17:02:05 ath10k.candelatech.com kernel:  0000000000000000 ffff8801fe0ab3b8 ffffffff8137086d 0000000000000000
Mar 25 17:02:05 ath10k.candelatech.com kernel:  0000000000000009 ffff8801fe0ab3f0 ffffffff810ee1eb ffffffffa07f5bba
Mar 25 17:02:05 ath10k.candelatech.com kernel:  ffff8800cadf9000 ffff880213770a60 00000000fffffffe ffff880204478a40
Mar 25 17:02:05 ath10k.candelatech.com kernel: Call Trace:
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8137086d>] dump_stack+0x81/0xb6
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff810ee1eb>] warn_slowpath_common+0x94/0xad
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa07f5bba>] ? __sta_info_destroy_part1+0x91/0x422 [mac80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff810ee2a8>] warn_slowpath_null+0x15/0x17
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa07f5bba>] __sta_info_destroy_part1+0x91/0x422 [mac80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa07f9474>] __sta_info_flush+0xd4/0x162 [mac80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa083a0a7>] ieee80211_set_disassoc+0x15e/0x31f [mac80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa083ea6c>] ieee80211_mgd_deauth+0x1e4/0x225 [mac80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa080cdcb>] ieee80211_deauth+0x13/0x15 [mac80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa05c27e9>] cfg80211_mlme_deauth+0x154/0x1e6 [cfg80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa05c2b16>] cfg80211_mlme_down+0x7a/0x9b [cfg80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa05c6b87>] cfg80211_disconnect+0xd4/0x24e [cfg80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa059e19a>] __cfg80211_leave+0x11f/0x16a [cfg80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa059e20d>] cfg80211_leave+0x28/0x37 [cfg80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa059e3dd>] cfg80211_netdev_notifier_call+0x1c1/0x5f4 [cfg80211]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff816de857>] ? rcu_read_unlock+0x3e/0x5d
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8110a75f>] notifier_call_chain+0x45/0x67
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8110a79b>] raw_notifier_call_chain+0xf/0x11
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81636381>] call_netdevice_notifiers_info+0x4d/0x54
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81636396>] call_netdevice_notifiers+0xe/0x10
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8163648c>] __dev_close_many+0x6c/0xd2
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81636524>] __dev_close+0x32/0x47
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8163ef6e>] __dev_change_flags+0xa4/0x13a
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8163f023>] dev_change_flags+0x1f/0x54
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8164a34f>] do_setlink+0x2fb/0x958
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8164d823>] rtnl_newlink+0x363/0x6c2
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff816361e7>] ? netdev_master_upper_dev_get+0xd/0x50
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8164d5be>] ? rtnl_newlink+0xfe/0x6c2
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff810f5e7d>] ? ns_capable+0x43/0x5a
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8164dcf8>] rtnetlink_rcv_msg+0x176/0x185
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff816493ca>] ? rtnl_lock+0x12/0x14
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112eb5c>] ? lock_release+0x1bb/0x3bd
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8164db82>] ? rtnl_newlink+0x6c2/0x6c2
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81669293>] netlink_rcv_skb+0x45/0x89
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81649fe0>] rtnetlink_rcv+0x1e/0x25
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81668c0a>] netlink_unicast+0xdc/0x154
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8166913d>] netlink_sendmsg+0x4bb/0x4d2
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8162477d>] sock_sendmsg+0x2e/0x3f
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81625095>] ___sys_sendmsg+0x1bb/0x253
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81152de0>] ? current_kernel_time64+0xb/0x31
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112eb5c>] ? lock_release+0x1bb/0x3bd
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112eb5c>] ? lock_release+0x1bb/0x3bd
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112e908>] ? lock_acquire+0x132/0x1cb
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81152a9c>] ? read_seqcount_begin.constprop.23+0x6b/0x87
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112d490>] ? trace_hardirqs_on_caller+0x16f/0x18b
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81225af1>] ? __fget_light+0x48/0x6c


Later, the station cannot be re-added because it at least partially exists in the
stack.  That ath10k splat seems to be because there is no channel-req associated
with the station.

Mar 25 17:02:05 ath10k.candelatech.com kernel: WARNING: CPU: 3 PID: 6 at /home/greearb/git/linux-4.4.dev.y/drivers/net/wireless/ath/ath10k/mac.c:6119 
ath10k_sta_rc_update_wk+0x3e/0x2d1 [ath10k_core]()
Mar 25 17:02:05 ath10k.candelatech.com kernel: Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv4 8021q garp mrp stp llc bnep 
bluetooth fuse macvlan wanlink(O) pktgen rpcsec_gss_krb5 nfsv4 nfs fscache iTCO_wdt iTCO_vendor_support coretemp hwmon ath9k intel_rapl iosf_mbi ath10k_pci 
ath9k_common ath10k_core ath9k_hw x86_pkg_temp_thermal intel_powerclamp kvm_intel ath kvm mac80211 joydev irqbypass serio_raw snd_hda_codec_hdmi pcspkr 
snd_hda_codec_realtek cfg80211 snd_hda_codec_generic i2c_i801 lpc_ich snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm 
8250_fintek snd_timer snd shpchp soundcore tpm_tis tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc ata_generic pata_acpi i915 i2c_algo_bit drm_kms_helper e1000e 
ptp pps_core drm i2c_core fjes video ipv6 [last unloaded: nf_conntrack]
Mar 25 17:02:05 ath10k.candelatech.com kernel:
Mar 25 17:02:05 ath10k.candelatech.com kernel: CPU: 3 PID: 6 Comm: kworker/u8:0 Tainted: G        W  O    4.4.6+ #21
Mar 25 17:02:05 ath10k.candelatech.com kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./HURONRIVER, BIOS 4.6.5 05/02/2012
Mar 25 17:02:05 ath10k.candelatech.com kernel: Workqueue: phy2 ath10k_sta_rc_update_wk [ath10k_core]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  0000000000000000 ffff880215093cf0 ffffffff8137086d 0000000000000000
Mar 25 17:02:05 ath10k.candelatech.com kernel:  0000000000000009 ffff880215093d28 ffffffff810ee1eb ffffffffa0e7ae8d
Mar 25 17:02:05 ath10k.candelatech.com kernel:  ffff880213774340 ffff8800cadf9be0 ffff88020447a2e0 ffff88021557cb80
Mar 25 17:02:05 ath10k.candelatech.com kernel: Call Trace:
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8137086d>] dump_stack+0x81/0xb6
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff810ee1eb>] warn_slowpath_common+0x94/0xad
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa0e7ae8d>] ? ath10k_sta_rc_update_wk+0x3e/0x2d1 [ath10k_core]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff810ee2a8>] warn_slowpath_null+0x15/0x17
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffffa0e7ae8d>] ath10k_sta_rc_update_wk+0x3e/0x2d1 [ath10k_core]
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8112b2a9>] ? __lock_is_held+0x3c/0x57
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff8110471a>] process_one_work+0x260/0x4db
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81104e50>] worker_thread+0x1e9/0x29b
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81104c67>] ? rescuer_thread+0x2a8/0x2a8
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81109bfb>] kthread+0xcf/0xd7
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81109b2c>] ? kthread_parkme+0x1f/0x1f
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff816faaef>] ret_from_fork+0x3f/0x70
Mar 25 17:02:05 ath10k.candelatech.com kernel:  [<ffffffff81109b2c>] ? kthread_parkme+0x1f/0x1f
Mar 25 17:02:05 ath10k.candelatech.com kernel: ---[ end trace e474c50f3cdc951c ]---
Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28: 04:f0:21:99:9e:d1 authenticate with 04:f0:21:f6:85:1c at: 1458950525.415842
Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28: failed to insert STA entry for the AP (error -17)

There seems to be no good way to recover from this.

There is a bunch more craziness in the logs too.  I've uploaded them here in case someone
wants to take a look.

http://www.candelatech.com/~greearb/misc/sta_insert_bug.txt

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: hashing error in hacked 4.4.6+ kernel.
  2016-03-26  0:56 hashing error in hacked 4.4.6+ kernel Ben Greear
@ 2016-03-26 19:20 ` Johannes Berg
  2016-03-26 19:50   ` Ben Greear
  0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2016-03-26 19:20 UTC (permalink / raw)
  To: Ben Greear, linux-wireless

On Fri, 2016-03-25 at 17:56 -0700, Ben Greear wrote:
> 
> Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28:
> deauthenticating from 04:f0:21:f6:85:1c by local choice (Reason:
> 3=DEAUTH_LEAVING)
> Mar 25 17:02:05 ath10k.candelatech.com kernel: ------------[ cut here
> ]------------
> Mar 25 17:02:05 ath10k.candelatech.com kernel: WARNING: CPU: 2 PID:
> 6227 at /home/greearb/git/linux-
> 4.4.dev.y/net/mac80211/sta_info.c:921 
> __sta_info_destroy_part1+0x91/0x422 [mac80211]()

In upstream, this warning goes straight to rhashtable not finding the
entry.

In your code though (looking at the commit introducing it, hoping you
didn't change it later), there's considerably more code in
sta_info_hash_del() that can return an error. It might be interesting
to find out *which* error is happening.

I'd agree though, from my brief look at the code it doesn't seem likely
that there's a problem with the code you add.

johannes

PS: you should probably write "return 0" instead of "return rv"
whenever it's clear that "rv" must be 0 :)

PPS: why are you not using rhashtable for the vhash?

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: hashing error in hacked 4.4.6+ kernel.
  2016-03-26 19:20 ` Johannes Berg
@ 2016-03-26 19:50   ` Ben Greear
  2016-03-28 18:25     ` Ben Greear
  0 siblings, 1 reply; 4+ messages in thread
From: Ben Greear @ 2016-03-26 19:50 UTC (permalink / raw)
  To: Johannes Berg, linux-wireless



On 03/26/2016 12:20 PM, Johannes Berg wrote:
> On Fri, 2016-03-25 at 17:56 -0700, Ben Greear wrote:
>>
>> Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28:
>> deauthenticating from 04:f0:21:f6:85:1c by local choice (Reason:
>> 3=DEAUTH_LEAVING)
>> Mar 25 17:02:05 ath10k.candelatech.com kernel: ------------[ cut here
>> ]------------
>> Mar 25 17:02:05 ath10k.candelatech.com kernel: WARNING: CPU: 2 PID:
>> 6227 at /home/greearb/git/linux-
>> 4.4.dev.y/net/mac80211/sta_info.c:921
>> __sta_info_destroy_part1+0x91/0x422 [mac80211]()
>
> In upstream, this warning goes straight to rhashtable not finding the
> entry.
>
> In your code though (looking at the commit introducing it, hoping you
> didn't change it later), there's considerably more code in
> sta_info_hash_del() that can return an error. It might be interesting
> to find out *which* error is happening.
>
> I'd agree though, from my brief look at the code it doesn't seem likely
> that there's a problem with the code you add.

In my current code, I'm always returning whatever the rhashtable returned
(rv is never actually assigned after that).  I figured that was
most likely to not introduce bugs.

http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary

or, grab the whole thing for easier looking:

git clone git://dmz2.candelatech.com/linux-4.4.dev.y

> johannes
>
> PS: you should probably write "return 0" instead of "return rv"
> whenever it's clear that "rv" must be 0 :)
>
> PPS: why are you not using rhashtable for the vhash?

Err, I was confused by the usage of rhashtable...and I had working
and tested code that patched in pretty easily.  Since it was not needed
upstream anyway, that seemed simplest.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: hashing error in hacked 4.4.6+ kernel.
  2016-03-26 19:50   ` Ben Greear
@ 2016-03-28 18:25     ` Ben Greear
  0 siblings, 0 replies; 4+ messages in thread
From: Ben Greear @ 2016-03-28 18:25 UTC (permalink / raw)
  To: Johannes Berg, linux-wireless

So, it appears at least part of the problem is that the station is not
added to the hash to begin with, and existing code does not check for that failure
or deal with it.  I added a check and I see this below.

That -16 value means EBUSY from what I can tell, because two rehashes
are scheduled at once (see hashtable_insert_rehash)

What we can do to protect against this?


ath10k_pci 0000:05:00.0: ATH10K_END
ath10k_pci 0000:05:00.0: Unknown eventid: 36898
sta10: 04:f0:21:db:c8:d1 authenticate with 04:f0:21:f6:85:1c at: 1459188823.781974
------------[ cut here ]------------
WARNING: CPU: 2 PID: 3114 at /home/greearb/git/linux-4.4.dev.y/net/mac80211/sta_info.c:327 sta_info_insert_finish+0x2d1/0x6da [mac80211]()
Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv4 8021q garp mrp stp llc bnep bluetooth fuse macvlan wanlink(O) pktgen 
rpcsec_gss_krb5 nfsv4 nfs fscache iTCO_wdt iTCO_vendor_support coretemp ath9k hwmon ath10k_pci intel_rapl iosf_mbi ath9k_common ath10k_core ath9k_hw 
x86_pkg_temp_thermal intel_powerclamp kvm_intel ath joydev kvm mac80211 irqbypass serio_raw pcspkr cfg80211 snd_hda_codec_hdmi lpc_ich i2c_i801 
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm 8250_fintek snd_timer snd shpchp 
soundcore tpm_tis tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc ata_generic pata_acpi e1000e ptp i915 i2c_algo_bit pps_core drm_kms_helper drm i2c_core video 
fjes ipv6 [last unloaded: nf_conntrack]
CPU: 0 PID: 3114 Comm: wpa_supplicant Tainted: G        W  O    4.4.6+ #21
Hardware name: To be filled by O.E.M. To be filled by O.E.M./HURONRIVER, BIOS 4.6.5 05/02/2012
ath10k_pci 0000:05:00.0: ath10k_pci ATH10K_DBG_BUFFER:
ath10k: [0000]: 000092F4 07FC4C02 00000001 000092F4 07FC4C02 00000001 000092FF 082C3812
ath10k: [0008]: 000F5C2C 0042507C 000092FF 102C3809 0000143C 00000001 00000000 00000000
ath10k: [0016]: 00009348 17FC5823 004402E0 851C0000 00000000 00000040 00000001 0000934A
ath10k: [0024]: 17FC4C01 0F00851C 0000000A 06003007 0000FFAA FFFFFFFF 0000934B 17FC4C01
ath10k: [0032]: 71108880 00000000 00C400BF 00000000 00000FF0 0000934B 17FC4C01 71108880
ath10k: [0040]: 00010000 00C400BF 00000000 FFFFFFFF 0000934B 17FC4C01 71108880 00020000
ath10k: [0048]: 00C400BF 00000000 FFFFFFFF 0000934B 17FC4C01 71108880 00030000 00C400BF
ath10k: [0056]: 000000FF FFFFFFFF 0000934B 17FC4C01 71108880 00040000 00C400BF 000000FF
ath10k: [0064]: FFFFFFFF 0000934B 17FC4C01 71108880 00050000 00C400BF 000000FF FBFFFFFF
ath10k_pci 0000:05:00.0: ATH10K_END
  0000000000000000 ffff8801fee5b490 ffffffff8137086d 0000000000000000
  0000000000000009 ffff8801fee5b4c8 ffffffff810ee1eb ffffffffa07d4519
  ffff8800d5350a60 00000000fffffff0 ffff8801ff330000 ffff8800cec6ca40
Call Trace:
  [<ffffffff8137086d>] dump_stack+0x81/0xb6
  [<ffffffff810ee1eb>] warn_slowpath_common+0x94/0xad
  [<ffffffffa07d4519>] ? sta_info_insert_finish+0x2d1/0x6da [mac80211]
  [<ffffffff810ee2a8>] warn_slowpath_null+0x15/0x17
  [<ffffffffa07d4519>] sta_info_insert_finish+0x2d1/0x6da [mac80211]
  [<ffffffff81144bb6>] ? rcu_read_lock_sched_held+0x54/0x5c
  [<ffffffffa0e6cff5>] ? ath10k_dbg_dump+0x1cc/0x259 [ath10k_core]
  [<ffffffff8112dda4>] ? __lock_acquire+0x641/0xde7
  [<ffffffffa0f53608>] ? ath10k_pci_hif_tx_sg+0x48/0x1b7 [ath10k_pci]
  [<ffffffff8112b2a9>] ? __lock_is_held+0x3c/0x57
  [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201
  [<ffffffff8112d30b>] ? mark_held_locks+0x5e/0x74
  [<ffffffff810f23a8>] ? __local_bh_enable_ip+0x9f/0xb9
  [<ffffffff8112d490>] ? trace_hardirqs_on_caller+0x16f/0x18b
  [<ffffffffa0f53742>] ? ath10k_pci_hif_tx_sg+0x182/0x1b7 [ath10k_pci]
  [<ffffffff8112d4b9>] ? trace_hardirqs_on+0xd/0xf
  [<ffffffff810f23ad>] ? __local_bh_enable_ip+0xa4/0xb9
  [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201
  [<ffffffff8112dda4>] ? __lock_acquire+0x641/0xde7
  [<ffffffffa07d5204>] ? sta_info_insert_rcu+0xa0/0xb7 [mac80211]
  [<ffffffff8112b2a9>] ? __lock_is_held+0x3c/0x57
  [<ffffffff8112b30d>] ? lock_is_held+0x49/0x50
  [<ffffffff8112b2a9>] ? __lock_is_held+0x3c/0x57
  [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201
  [<ffffffff8112d30b>] ? mark_held_locks+0x5e/0x74
  [<ffffffff816f7131>] ? mutex_lock_nested+0x32e/0x3cf
  [<ffffffff8112d490>] ? trace_hardirqs_on_caller+0x16f/0x18b
  [<ffffffff816f7139>] ? mutex_lock_nested+0x336/0x3cf
  [<ffffffffa07d5204>] ? sta_info_insert_rcu+0xa0/0xb7 [mac80211]
  [<ffffffff8110f621>] ? ___might_sleep+0xc8/0x1ba
  [<ffffffffa07d520c>] sta_info_insert_rcu+0xa8/0xb7 [mac80211]
  [<ffffffffa07d5225>] sta_info_insert+0xa/0x17 [mac80211]
  [<ffffffffa0817630>] ieee80211_prep_connection+0x743/0x78e [mac80211]
  [<ffffffffa081c02c>] ieee80211_mgd_auth+0x20f/0x2cd [mac80211]
  [<ffffffffa05b67e5>] ? cfg80211_get_bss+0x26d/0x2ec [cfg80211]
  [<ffffffff8112b2a9>] ? __lock_is_held+0x3c/0x57
  [<ffffffffa07eae2a>] ieee80211_auth+0x13/0x15 [mac80211]
  [<ffffffffa05d334d>] cfg80211_mlme_auth+0x1d8/0x277 [cfg80211]
  [<ffffffffa05c96d2>] nl80211_authenticate+0x25b/0x283 [cfg80211]
  [<ffffffff8166ac78>] genl_family_rcv_msg+0x23a/0x28a
  [<ffffffff8166ad07>] genl_rcv_msg+0x3f/0x58
  [<ffffffff8166acc8>] ? genl_family_rcv_msg+0x28a/0x28a
  [<ffffffff81669293>] netlink_rcv_skb+0x45/0x89
  [<ffffffff816698db>] genl_rcv+0x23/0x32
  [<ffffffff81668c0a>] netlink_unicast+0xdc/0x154
  [<ffffffff8166913d>] netlink_sendmsg+0x4bb/0x4d2
  [<ffffffff8162477d>] sock_sendmsg+0x2e/0x3f
  [<ffffffff81625095>] ___sys_sendmsg+0x1bb/0x253
  [<ffffffff81152de0>] ? current_kernel_time64+0xb/0x31
  [<ffffffff8112eb5c>] ? lock_release+0x1bb/0x3bd
  [<ffffffff8112e928>] ? lock_acquire+0x152/0x1cb
  [<ffffffff8112eb5c>] ? lock_release+0x1bb/0x3bd
  [<ffffffff8112e908>] ? lock_acquire+0x132/0x1cb
  [<ffffffff81152a9c>] ? read_seqcount_begin.constprop.23+0x6b/0x87
  [<ffffffff8112d490>] ? trace_hardirqs_on_caller+0x16f/0x18b
  [<ffffffff81225af1>] ? __fget_light+0x48/0x6c
  [<ffffffff81625403>] __sys_sendmsg+0x3d/0x5b
  [<ffffffff81625403>] ? __sys_sendmsg+0x3d/0x5b
  [<ffffffff8162542e>] SyS_sendmsg+0xd/0x17
  [<ffffffff816fa736>] entry_SYSCALL_64_fastpath+0x16/0x7a
---[ end trace 6a7a92839dd92121 ]---
info-hash-add, rv: -16 addr: 04:f0:21:f6:85:1c
sta10: send auth to 04:f0:21:f6:85:1c (try 1/3) at: 1459188824.431766
sta10: authenticated at: 1459188824.440810
ath10k_pci 0000:05:00.0: band: 1  ratemask: 0xff  hw-nss: 4
sta10: associate with 04:f0:21:f6:85:1c (try 1/3)
ath10k_pci 0000:05:00.0: Unknown eventid: 36898
sta10: RX AssocResp from 04:f0:21:f6:85:1c (capab=0x11 status=0 aid=21) at: 1459188824.470288
ath10k_pci 0000:05:00.0: band: 1  ratemask: 0xff  hw-nss: 4
ath10k_pci 0000:05:00.0: Unknown eventid: 36898
IPv6: ADDRCONF(NETDEV_CHANGE): sta10: link becomes ready
sta10: associated at: 1459188824.488553
ath10k_pci 0000:05:00.0: band: 1  ratemask: 0xff  hw-nss: 4
ath10k_pci 0000:05:00.0: band: 1  ratemask: 0xff  hw-nss: 4
ath10k_pci 0000:05:00.0: band: 1  ratemask: 0xff  hw-nss: 4
ath10k_pci 0000:05:00.0: band: 1  ratemask: 0xff  hw-nss: 4
sta13: 04:f0:21:88:43:d1 authenticate with 04:f0:21:f6:85:1c at: 1459188824.508504
ath10k_pci 0000:05:00.0: Unknown eventid: 36898
ath10k_pci 0000:05:00.0: Unknown eventid: 36898
ath10k_pci 0000:05:00.0: Unknown eventid: 36898
....


/* Caller must hold local->sta_mtx */
static void sta_info_hash_add(struct ieee80211_local *local,
			      struct sta_info *sta)
{
	int idx = STA_HASH(sta->sta.addr);
	int rv;

	rv = rhashtable_insert_fast(&local->sta_hash, &sta->hash_node,
				    sta_rht_params);
	WARN_ON(rv);
	pr_err("info-hash-add, rv: %d addr: %pM\n", rv, sta->sta.addr);

	sta->vnext = sta->sdata->sta_vhash[idx];
	rcu_assign_pointer(sta->sdata->sta_vhash[idx], sta);
}


Thanks,
Ben


On 03/26/2016 12:50 PM, Ben Greear wrote:
>
>
> On 03/26/2016 12:20 PM, Johannes Berg wrote:
>> On Fri, 2016-03-25 at 17:56 -0700, Ben Greear wrote:
>>>
>>> Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28:
>>> deauthenticating from 04:f0:21:f6:85:1c by local choice (Reason:
>>> 3=DEAUTH_LEAVING)
>>> Mar 25 17:02:05 ath10k.candelatech.com kernel: ------------[ cut here
>>> ]------------
>>> Mar 25 17:02:05 ath10k.candelatech.com kernel: WARNING: CPU: 2 PID:
>>> 6227 at /home/greearb/git/linux-
>>> 4.4.dev.y/net/mac80211/sta_info.c:921
>>> __sta_info_destroy_part1+0x91/0x422 [mac80211]()
>>
>> In upstream, this warning goes straight to rhashtable not finding the
>> entry.
>>
>> In your code though (looking at the commit introducing it, hoping you
>> didn't change it later), there's considerably more code in
>> sta_info_hash_del() that can return an error. It might be interesting
>> to find out *which* error is happening.
>>
>> I'd agree though, from my brief look at the code it doesn't seem likely
>> that there's a problem with the code you add.
>
> In my current code, I'm always returning whatever the rhashtable returned
> (rv is never actually assigned after that).  I figured that was
> most likely to not introduce bugs.
>
> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary
>
> or, grab the whole thing for easier looking:
>
> git clone git://dmz2.candelatech.com/linux-4.4.dev.y
>
>> johannes
>>
>> PS: you should probably write "return 0" instead of "return rv"
>> whenever it's clear that "rv" must be 0 :)
>>
>> PPS: why are you not using rhashtable for the vhash?
>
> Err, I was confused by the usage of rhashtable...and I had working
> and tested code that patched in pretty easily.  Since it was not needed
> upstream anyway, that seemed simplest.
>
> Thanks,
> Ben
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-03-28 18:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-26  0:56 hashing error in hacked 4.4.6+ kernel Ben Greear
2016-03-26 19:20 ` Johannes Berg
2016-03-26 19:50   ` Ben Greear
2016-03-28 18:25     ` Ben Greear

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.