Commit a87b9ebf authored by Thomas Graf's avatar Thomas Graf Committed by David S. Miller

rhashtable: Do not schedule more than one rehash if we can't grow further

The current code currently only stops inserting rehashes into the
chain when no resizes are currently scheduled. As long as resizes
are scheduled and while inserting above the utilization watermark,
more and more rehashes will be scheduled.

This lead to a perfect DoS storm with thousands of rehashes
scheduled which lead to thousands of spinlocks to be taken
sequentially.

Instead, only allow either a series of resizes or a single rehash.
Drop any further rehashes and return -EBUSY.

Fixes: ccd57b1b ("rhashtable: Add immediate rehash during insertion")
Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent e2307ed6
...@@ -405,8 +405,8 @@ int rhashtable_insert_rehash(struct rhashtable *ht) ...@@ -405,8 +405,8 @@ int rhashtable_insert_rehash(struct rhashtable *ht)
if (rht_grow_above_75(ht, tbl)) if (rht_grow_above_75(ht, tbl))
size *= 2; size *= 2;
/* More than two rehashes (not resizes) detected. */ /* Do not schedule more than one rehash */
else if (WARN_ON(old_tbl != tbl && old_tbl->size == size)) else if (old_tbl != tbl)
return -EBUSY; return -EBUSY;
new_tbl = bucket_table_alloc(ht, size, GFP_ATOMIC); new_tbl = bucket_table_alloc(ht, size, GFP_ATOMIC);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment