Thread (16 messages) 16 messages, 4 authors, 2016-04-02

Re: Question on rhashtable in worst-case scenario.

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2016-03-30 13:55:31
Also in: lkml, netdev

Possibly related (same subject, not in this thread)

On Wed, Mar 30, 2016 at 11:14:12AM +0200, Johannes Berg wrote:
On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote:
quoted
Looks like rhashtable has too much policy in it to properly deal with
cases where there are too many hash collisions, so I am going to work
on reverting it's use in mac80211.
I'm not really all that happy with that approach - can't we fix the
rhashtable? It's a pretty rare corner case that many keys really are
identical and no kind of hash algorithm, but it seems much better to
still deal with it than to remove the rhashtable usage and go back to
hand-rolling something.
Well to start with you should assess whether you really want to
hash multiple objects with the same key.  In particular, can an
adversary generate a large number of such objects?

If your conclusion is that yes you really want to do this, then
we have the parameter insecure_elasticity that you can use to
disable the rehashing based on chain length.

Cheers,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help