On 03/31/2016 05:46 PM, Herbert Xu wrote:
On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote:
Does removing this completely disable the "-EEXIST" error? I can't say
I fully understand the elasticity stuff in __rhashtable_insert_fast().
What EEXIST error are you talking about? The only one that can be
returned on insertion is if you're explicitly checking for dups
which clearly can't be the case for you.
If you're talking about the EEXIST error due to a rehash then it is
completely hidden from you by rhashtable_insert_rehash.
If you actually meant EBUSY then yes this should prevent it from
occurring, unless your chain-length exceeds 2^32.
EEXIST was on removal, and was a symptom of the failure to insert, not
really a problem itself.
I reverted my revert (ie, back to rhashtable), added Johanne's patch
to check insertion (and added my on pr_err there).
I also added this:
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 38ef0be..c25b945 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -66,6 +66,7 @@
static const struct rhashtable_params sta_rht_params = {
.nelem_hint = 3, /* start small */
+ .insecure_elasticity = true, /* Disable chain-length checks. */
.automatic_shrinking = true,
.head_offset = offsetof(struct sta_info, hash_node),
.key_offset = offsetof(struct sta_info, addr),
Now, my test case seems to pass, though I did have one strange issue
before I put in the pr_err. I'm not sure if it was a hashtable issue
or something else..but I have lots of something-else going on in this system,
so I'd say that likely the patch above fixes rhashtable for my use case.
I will of course let you know if I run into more issues that appear
to be hashtable related!
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
