Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[BUG\]\s+overflow\s+in\s+net\/ipv4\/route\.c\s+rt_check_expire\(\)\s*$/: 68 ]

Total 68 documents matching your query.

1. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Date: Fri, 01 Apr 2005 16:39:48 +0200
David S. Miller a écrit : On Thu, 17 Mar 2005 20:52:44 +0100 Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: - Move the spinlocks out of tr_hash_table[] to a fixed size table : Saves a lot of memory (par
/archives/netdev/2005-04/msg00014.html (10,718 bytes)

2. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 1 Apr 2005 17:53:02 +0200
Did you check for performance changes too? From what I understand we can add new lookup and cache miss in the fast packet path. IMO we should be careful with adding new complexity the route hash. Al
/archives/netdev/2005-04/msg00015.html (10,065 bytes)

3. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Date: Fri, 01 Apr 2005 18:34:18 +0200
Robert Olsson a écrit : Did you check for performance changes too? From what I understand we can add new lookup and cache miss in the fast packet path. Performance is better because in case of stre
/archives/netdev/2005-04/msg00017.html (11,905 bytes)

4. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 1 Apr 2005 19:26:32 +0200
Would like to see absolute numbers for UP/SMP single flow and DoS to be confident. I don't think you can depend on timer for GC solely. Timer tick is eternity for todays packet rates. You can distrib
/archives/netdev/2005-04/msg00020.html (10,918 bytes)

5. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Fri, 1 Apr 2005 12:28:02 -0800
Right. Even for NR_CPUS, I think the table should be dynamically allocated. It is a goal to eliminate all of these huge arrays in the static kernel image, which has grown incredibly too much in recen
/archives/netdev/2005-04/msg00026.html (10,496 bytes)

6. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Date: Fri, 01 Apr 2005 23:05:37 +0200
David S. Miller a écrit : On Fri, 01 Apr 2005 16:39:48 +0200 Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: Maybe I should make a static sizing, (replace the 256 constant by something based on MAX_CPUS
/archives/netdev/2005-04/msg00028.html (11,650 bytes)

7. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Fri, 1 Apr 2005 13:08:32 -0800
In the former case the kernel image the bootloader has to load is smaller. That's important, believe it or not. It means less TLB entries need to be locked permanently into the MMU on certain platfor
/archives/netdev/2005-04/msg00030.html (10,893 bytes)

8. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Date: Fri, 01 Apr 2005 23:43:38 +0200
David S. Miller a écrit : On Fri, 01 Apr 2005 23:05:37 +0200 Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: You mean you prefer : static spinlock_t *rt_hash_lock ; /* rt_hash_lock = alloc_memory_at_boot
/archives/netdev/2005-04/msg00034.html (13,244 bytes)

9. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Fri, 1 Apr 2005 14:34:42 -0800
Sure, that's fine. BTW, please line-wrap your emails. :-/
/archives/netdev/2005-04/msg00035.html (11,094 bytes)

10. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Date: Sat, 02 Apr 2005 01:21:49 +0200
David S. Miller a écrit : On Fri, 01 Apr 2005 23:43:38 +0200 Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: Are you OK if I also use alloc_large_system_hash() to allocate rt_hash_table, instead of the c
/archives/netdev/2005-04/msg00037.html (31,399 bytes)

11. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Fri, 1 Apr 2005 15:54:42 -0800
Looks fine to me. I'd like to see some feedback from folks like Robert Olsson and co. before applying this, so let's allow the patch to simmer over the weekend, ok? :-)
/archives/netdev/2005-04/msg00045.html (12,031 bytes)

12. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 02 Apr 2005 18:21:05 +1000
This patch is doing too many things. How about splitting it up? For instance the spin lock stuff is pretty straightforward and should be in its own patch. The benefits of the GC changes are not obvio
/archives/netdev/2005-04/msg00063.html (11,955 bytes)

13. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Date: Sat, 02 Apr 2005 11:21:30 +0200
Herbert Xu a écrit : Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: OK this patch includes everything... - Locking abstraction - rt_check_expire() fixes - New gc_interval_ms sysctl to be able to have ti
/archives/netdev/2005-04/msg00065.html (14,625 bytes)

14. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Sat, 2 Apr 2005 15:48:32 +0200
Yes a good idea so it can be tested separatly.... Agree with Herbert... Yes thats a pretty much load. Very short flows some reason? What's your ip_rt_gc_min_interval? GC should be allowed to run freq
/archives/netdev/2005-04/msg00071.html (12,022 bytes)

15. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Date: Sat, 02 Apr 2005 16:10:10 +0200
Robert Olsson a écrit : Eric Dumazet writes: Yes thats a pretty much load. Very short flows some reason? Well... yes. This is a real server, not a DOS simulation. 1 million TCP flows, and about 3 m
/archives/netdev/2005-04/msg00075.html (12,410 bytes)

16. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Sat, 2 Apr 2005 16:46:31 +0200
I see. OK! Not so bad. Most of your GC likely happens in rt_intern_hash chain pruning. This way you keep hash-chains short and get "datadriven" GC. But there must be bugs causing the crash... Maybe t
/archives/netdev/2005-04/msg00076.html (11,780 bytes)

17. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 3 Apr 2005 05:32:24 +1000
Incidentally we should change the way the rehashing is triggered. Instead of doing it regularly, we can do it when we notice that a specific hash chain grows beyond a certain size. The idea is that i
/archives/netdev/2005-04/msg00088.html (11,647 bytes)

18. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Sat, 2 Apr 2005 11:55:28 -0800
Yes, the secret_interval is way too short. It is a very paranoid default value selected when initially fixing that DoS. I think we should, in the short term, increase the secret interval where it exi
/archives/netdev/2005-04/msg00090.html (11,682 bytes)

19. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: 02 Apr 2005 15:47:36 -0500
SMP? How many processors? cheers, jamal
/archives/netdev/2005-04/msg00091.html (11,258 bytes)

20. Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() (score: 1)
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 3 Apr 2005 17:43:37 +1000
We could also move rt_cache_flush into a kernel thread. When the number of chains is large this function is really expensive for a softirq handler. Cheers, -- Visit Openswan at http://www.openswan.or
/archives/netdev/2005-04/msg00104.html (11,552 bytes)


This search system is powered by Namazu