I looked at this too. The callout_deactivate() is called
within the invoked callout routine. AFAIK it's only to ensure
that 'unarmed' timeouts are marked as inactive too, to get easy
way to determine whether or not a timeout is 'armed' or 'executing'.

Callout is always one time thing, i.e. only ever called once.  It
must be callout_reset() to launch it again.  Note that most tcp
timeout routines eventually do call TCP_TIMER_ARM() and thus
callout_reset(), unless some serious network problem is detected.

The callout_deactivate() calls seem to be right IMHO.

Jaromir

David Laight wrote:
> I've just found what looks like a bug in the TCP timeout code.
> (This is from reading the sources!)
> 
> The 'dubious' code is in rev 1.53 of tcp_timer.c (10 Sep 2001),
> I don't know which release that refers to.
> 
> The TCP code was changed to use kernel callouts (instead of
> traversing the world  twice a second) - a not unreasonable change.
> 
> However the code calls 'callout_deactivate()' in order (I presume)
> to stop the timeout.  However callout_deactivate is:
> 
> #define callout_deactivate(c)   ((c)->c_flags &= ~CALLOUT_ACTIVE)
> 
> and, unless i'm misreading the code, the CALLOUT_ACTIVE flag
> has absolutely no effect on the callout routines.
> 
> I suspect this should be callout_stop() - but maybe something
> more subtle was intended.
> 
> 	David
> 
> -- 
> David Laight: david@l8s.co.uk
> 


-- 
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-