netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@suug.ch>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Miller <davem@davemloft.net>,
	johannes@sipsolutions.net, netdev@vger.kernel.org,
	kaber@trash.net, johannes.berg@intel.com
Subject: Re: rhashtable: Add cap on number of elements in hash table
Date: Fri, 24 Apr 2015 09:06:08 +0100	[thread overview]
Message-ID: <20150424080608.GM21799@casper.infradead.org> (raw)
In-Reply-To: <20150424005729.GA27075@gondor.apana.org.au>

On 04/24/15 at 08:57am, Herbert Xu wrote:
> It seems that I lost track somewhere along the line.  I meant
> to add an explicit limit on the overall number of entries since
> that was what users like netlink expected but never got around
> to doing it.  Instead it seems that we're currently relying on
> the rht_grow_above_100 to protect us.

Can we please just take Johannes's fix as-is first? It fixes
the bug at hand in an isolated manner without introducing any
new knobs. Your patch includes his fix as-is without modification
anyway.

> So here is a patch that adds an explicit limit and fixes the
> problem Johannes reported.
> 
> ---8<---
> We currently have no limit on the number of elements in a hash table.
> This is very bad especially considering that some rhashtable users
> had such a limit before the conversion and relied on it for defence
> against DoS attacks.

Which users are you talking about? Both Netlink and TIPC still
have an upper limit. nft sets are controlled by privileged users.

> We already have a maximum hash table size limit but its enforcement
> is only by luck and results in a nasty WARN_ON.

As I stated earlier, this is no longer the case and thus this
paragraph only confuses the commit message.

> This patch adds a new paramater insecure_max_entries which becomes
> the cap on the table.  If unset it defaults to max_size.  If it is
> also zero it means that there is no cap on the number of elements
> in the table.  However, the table will grow whenever the utilisation
> hits 100% and if that growth fails, you will get ENOMEM on insertion.

Last time we discussed this it was said that the caller should enforce
the limit like Netlink does.

I'm fine with adding an upper max but I'd like to discuss that in the
context of a full series which converts all existing enforcements and
also contains a testing mechanism to verify this. Also, unless you can
show me where this is currently a real bug, this is really net-next
material.

  parent reply	other threads:[~2015-04-24  8:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-23 14:38 [PATCH] rhashtable: don't attempt to grow when at max_size Johannes Berg
2015-04-23 15:59 ` David Miller
2015-04-23 16:09   ` Johannes Berg
2015-04-23 16:16     ` Daniel Borkmann
2015-04-24  0:57   ` rhashtable: Add cap on number of elements in hash table Herbert Xu
2015-04-24  7:01     ` Johannes Berg
2015-04-24  8:04       ` Herbert Xu
2015-04-24  8:06     ` Thomas Graf [this message]
2015-04-24  8:12       ` Herbert Xu
2015-04-24  8:15         ` Thomas Graf
2015-04-24  8:22           ` Herbert Xu
2015-04-24 15:38             ` David Miller
2015-05-13  8:06     ` Herbert Xu
2015-05-15  2:22       ` David Miller
2015-05-15  3:06         ` Herbert Xu
2015-05-15  3:46           ` David Miller
2015-05-15  6:30             ` Herbert Xu
2015-05-16 22:09               ` David Miller
2015-05-17  1:38                 ` Herbert Xu
2015-05-18 20:12                   ` David Miller
2015-05-18 22:35                     ` Herbert Xu
2015-05-19 10:25                       ` David Laight
2015-05-15  3:30       ` [v2 PATCH] " Herbert Xu
2015-05-16 22:08         ` David Miller
2015-04-23 20:46 ` [PATCH] rhashtable: don't attempt to grow when at max_size Thomas Graf
2015-04-23 20:49   ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150424080608.GM21799@casper.infradead.org \
    --to=tgraf@suug.ch \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=johannes.berg@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).