| To: | Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() |
| From: | Robert Olsson <Robert.Olsson@xxxxxxxxxxx> |
| Date: | Mon, 4 Apr 2005 12:38:03 +0200 |
| Cc: | Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, Eric Dumazet <dada1@xxxxxxxxxxxxx>, davem@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <20050403214358.GA15901@xxxxxxxxxxxxxxxxxxx> |
| References: | <E1DHdsP-0003Lr-00@xxxxxxxxxxxxxxxxxxxxxxxx> <424E641A.1020609@xxxxxxxxxxxxx> <16974.41648.568927.54429@xxxxxxxxxxxx> <20050402193224.GA25157@xxxxxxxxxxxxxxxxxxx> <16976.17876.832677.945878@xxxxxxxxxxxx> <20050403214358.GA15901@xxxxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
Herbert Xu writes:
> The only way to attack a hash is by exploiting collisions and
> create one or more excessively long chains.
>
> This can be detected as follows at each rt hash insertion. If
>
> (total number of entries in cache >> (hash length - user defined length)) <
> current bucket length
>
> is true, then we schedule a rehash/flush.
>
> Hash length is the number of bits in the hash, i.e.,
>
> 1 << hash length == number of buckets
>
> I'd suggest a default shift length of 3. That is, if any individual
> chain is growing beyond 8 times the average chain length then we've
> got a problem.
This is likely to happen in rt_intern_hash? I don't see how this can
get along with chain-pruning there?
IMO the thoughts of extending in-flow GC etc are interesting and can
hopefully give us more robust performance.
--ro
|
| Previous by Date: | Re: [BUG] overflow in net/ipv4/route.c rt_check_expire(), Robert Olsson |
|---|---|
| Next by Date: | Re: [BUG] overflow in net/ipv4/route.c rt_check_expire(), Herbert Xu |
| Previous by Thread: | Re: [BUG] overflow in net/ipv4/route.c rt_check_expire(), Herbert Xu |
| Next by Thread: | Re: [BUG] overflow in net/ipv4/route.c rt_check_expire(), Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |