[Click] [PATCH] timer tight loop fix

[Eddie Kohler]

Another awesome find and fix.  This patch I've applied essentially as is.  I 
think this fixes a real bug.  Thank you very much!!

Eddie


Nadi Sarrar wrote:
> Hi all.
> 
> Eddie, I already mailed this patch to you. For the sake of completeness, I also post
> this to the list, sorry for the duplication.
> 
> There seems to be a problem with the Click timers, which leads to 100% CPU
> utilization. It can be reproduced as follows (tested on three x86 machines):
> 
> (1) Compile Click with the attached timerdebug element included. I'm not using any
>     special configure flags, just --enable-local and --disable-linuxmodule.
> 
> (2) Start Click with timerdebug.click (also attached).
> 
> (3) Start netcat (i.e. 'nc -u 10.0.0.2 5000'), send some data and monitor CPU
>     utilization (I used 'top'). For me, 10 to 20 UDP packets were always enough to
>     trigger this problem.
> 
> I'm not sure whether the problem lies in my timerdebug element, but what seems
> to fix it, is the attached patch. The incident that triggers the problem begins
> in master.cc, at the end of timer_reheapify_from:
> 
> 	_timer_expiry = Timestamp();
> 
> This sets _timer_expiry to zero. Later, in master.hh::next_timer_expiry_adjusted(),
> if _timer_stride < 8, the value of _timer_expiry is taken, Timer::adjustment()
> is subtracted from it and returned, which then has the value:
> 
> 	e.sec = -1, e.subsec = 999500
> 
> Which leads to unintended behavior after the calls to
> next_timer_expiry_adjusted() in master.cc, see the if-clauses there. A
> timeout/wait value of zero is given to poll/select/kevent, where no timeout
> should be used instead.
> 
> Nadi
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click