Re: [RFC PATCH] inet: fix enforcing of fragment queue hash list depth

[Jesper Dangaard Brouer <brouer@redhat.com>]

On Mon, 2013-04-15 at 09:23 -0700, Eric Dumazet wrote:

> Allowing thousand of fragments and keeping a 64 slot hash table is not
> going to work.
> 
> depths of 128 are just insane.

I fully agree, my plan was actually to reduce this to 5 or 10 depth
limit.  I just noticed this problem with Hannes patch, while working on
your idea of direct hash cleaning, and then I just/only extracted the
parts that was relevant for fixing Hannes patch.


> Really Jesper, you'll need to make the hash table dynamic, if you really
> care.

My plan/idea is to make the hash tables size depend on the available
memory.  As on small memory devices, we are opening up for (an attack
vector where) remote hosts can pin-down a large portion of their memory,
which we want to avoid.  (And you don't even need a port in listen
state).

How dynamic do you want it?  Would initial sizing based on memory be
enough, or should I also add a proc/sysctl option for changing the hash
size from userspace?

--Jesper