Eric Dumazet wrote: > Le jeudi 22 avril 2010 à 22:38 +0200, Jesper Dangaard Brouer a écrit : >> On Thu, 22 Apr 2010, Eric Dumazet wrote: >> >>> Le jeudi 22 avril 2010 à 08:51 -0700, Paul E. McKenney a écrit : >>>> On Thu, Apr 22, 2010 at 04:53:49PM +0200, Eric Dumazet wrote: >>>>> Le jeudi 22 avril 2010 à 16:36 +0200, Eric Dumazet a écrit : >>>>> >>>>> If we can do the 'retry' a 10 times, it means the attacker was really >>>>> clever enough to inject new packets (new conntracks) at the right >>>>> moment, in the right hash chain, and this sounds so higly incredible >>>>> that I cannot believe it at all :) >>>> Or maybe the DoS attack is injecting so many new conntracks that a large >>>> fraction of the hash chains are being modified at any given time? >>>> >> I think its plausable, there is a lot of modification going on. >> Approx 40.000 deletes/sec and 40.000 inserts/sec. >> The hash bucket size is 300032, and with 80000 modifications/sec, we are >> (potentially) changing 26.6% of the hash chains each second. >> > > OK but a lookup last a fraction of a micro second, unless interrupted by > hard irq. > > Probability of a change during a lookup should be very very small. > > Note that the scenario for a restart is : > > The lookup go through the chain. > While it is examining one object, this object is deleted. > The object is re-allocated by another cpu and inserted to a new chain. I think another scenario that seems a bit more likely would be that a new entry is added to the chain after it was fully searched. Perhaps we could continue searching at the last position if the last entry is not a nulls entry to improve this. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
