On Fri, Apr 24, 2015 at 09:01:10AM +0200, Johannes Berg wrote: > > > As allowing >100% utilisation is potentially dangerous, the name > > contains the word insecure. > > Not sure I get this. So rhashtable is trying to actually never have > collisions? How could that possibly work?
Of course it's not to eliminate collisions, but to limit the chain length to something reasonable. Using a hashtable at >100% capacity is usually not reasonable. > Since you're also doing what I did here, would it make sense to apply my > patch to net and this one only to net-next? That would make af_netlink a security hole again because you can now add unlimited entries to a hash table limited to 64K entries. Prior to the rhashtable conversion you weren't allowed to have more than 64K entries in the table. This was lost in the conversion and I was trying to restore it. > For my use case (which was testing/debug) I don't actually care that > much, but perhaps that'd be an easier sell towards the end of the merge > window :) It seems that my patch would mostly fix the *issue*, while > yours actually adds a new parameter that's also not actually used yet. Well if my patch is too complex then sure we can look at coming up with a simpler fix but I think we need something that does not let you add unlimited entries to af_netlink. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
