| 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
| ||
|
Message-ID: <20150323214819.GB19938@gondor.apana.org.au> Date: Tue, 24 Mar 2015 08:48:20 +1100 From: Herbert Xu <herbert@...dor.apana.org.au> To: David Miller <davem@...emloft.net> Cc: tgraf@...g.ch, eric.dumazet@...il.com, kaber@...sh.net, josh@...htriplett.org, paulmck@...ux.vnet.ibm.com, netdev@...r.kernel.org Subject: Re: [v2 PATCH 7/10] rhashtable: Disable automatic shrinking On Mon, Mar 23, 2015 at 12:44:34PM -0400, David Miller wrote: > > The user can't do this with TCP? Why is netlink only susceptible? > > The only plausible argument for shrinking I've ever heard of is the > nft_hash case, and there that code can _explicitly_ ask for a shrink > after it has made a major table modification. > > That puts all of the smarts for when to shrink where the knowledge > resides, and in this case that's the user. One thing I got to say is that automatic shrinking is a really good stress test as reenabling it allowed me to quickly identify two bugs in the final patch :) Other than that I totally agree that it should be disabled by default as otherwise it increases the amortised cost of the hash table for a paltry saving in memory. We can do it afterwards once we're sure this whole thing is stable. Cheers, -- Email: Herbert Xu <herbert@...dor.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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists