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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
