lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 30 Mar 2016 12:38:21 -0400 (EDT) From: David Miller <davem@...emloft.net> To: johannes@...solutions.net Cc: greearb@...delatech.com, linux-kernel@...r.kernel.org, herbert@...dor.apana.org.au, linux-wireless@...r.kernel.org, netdev@...r.kernel.org, tgraf@...g.ch Subject: Re: Question on rhashtable in worst-case scenario. From: Johannes Berg <johannes@...solutions.net> Date: Wed, 30 Mar 2016 11:14:12 +0200 > On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote: >> 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. Yeah reverting seems like a really idiotic way to deal with the issue.
Powered by blists - more mailing lists