netdev - Re: [PATCH 3/3] rhashtable: Add nested tables

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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