Subject: Re: TCP problems - maybe a solution?
To: David Laight <>
From: Jaromir Dolecek <>
List: current-users
Date: 07/22/2002 14:47:44
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.


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:

Jaromir Dolecek <>
-=- 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.''     -=-