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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 8 Feb 2017 09:09:33 +0800 From: Herbert Xu <herbert@...dor.apana.org.au> To: Florian Westphal <fw@...len.de> Cc: "David S. Miller" <davem@...emloft.net>, Thomas Graf <tgraf@...g.ch>, netdev@...r.kernel.org Subject: Re: [PATCH 3/3] rhashtable: Add nested tables On Tue, Feb 07, 2017 at 07:02:16PM +0100, Florian Westphal wrote: > > I can't really say anything here because *I* don't expect > it to succeed. Think about incoming TCP connections, you can't rate-limit that without defeating yourself. > Even with this proposed patch things will eventually fail > on OOM conditions. Exactly. That's the only case where it should fail. Previously it would fail if we cannot allocate a large number of consecutive pages, which can happen even if you have lots of memory left. With my patch it will only fail if it cannot allocate at most two non- consecutive pages, i.e., a real OOM. > Also, such period should be very short until rht has reached > peak size for the workload. How would you know? The rate of insertions could be extremely high. > Also, given that we could easily oversubscribe a table by a factor > of 10 or more while still keeping sane chain lengths I don't > see why thats a problem (also, a 'rht_insert_force' or similar > interface that doesn't do chain length checks makes it > easy to spot places that need/want this behaviour). But you would still have to impose a limit, whether it's 1 or 10. IOW you will still fail insertions at some point even though you have sufficient memory to perform the insertion. > (insecure_elasticity and/or insecure_max_entries come to mind, seems > some of that might not even be needed anymore but I don't have time > right now to investigate). Yes insecure_elasticity is now obsolete and anyone using it should switch over to rhlist. Once nobody uses it then it can be removed. 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
Powered by blists - more mailing lists