lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ