New "timeout" api, to replace callout

[Robert Watson]

On Wed, 2 Jan 2008, Andre Oppermann wrote:

>> If you don't have the drain and softclock is trying to acquire the backing 
>> mutex while you have it held (before the callout_stop) then Bad Things can 
>> happen if you don't do the drain.  Having the lock just "give up" doesn't 
>> work either because if the memory containing the lock is free'd and 
>> reinitialized such that it looks enough like a valid lock then softclock 
>> (or its equivalent) will still try to obtain it.  Also, you need to do a 
>> drain so it is safe to free the callout structure to prevent it from being 
>> recycled and having weird races where it gets recycled and rescheduled but 
>> the timer code thinks it has a pending stop for that pointer and so it 
>> aborts the wrong instance of the timer, etc.
>
> This is all well known.  ;)  What isn't known is that this (the sleep part) 
> is a major problem for TCP due to being run from interrupt context.  Hence 
> the request for some kind of busy-drain or other method prevent the sleep. 
> A second less severe problem are races while the lock is dropped during the 
> sleep.  Here some other part of TCP may go into the tcpcb scheduled for 
> destruction.

We do need to fix this -- if it can be done by fixing the callout system, I'm 
all for it.  Otherwise we probably need to add a tcpcb GC thread that picks up 
the pieces in a sleepable context.

Robert N M Watson
Computer Laboratory
University of Cambridge