New "timeout" api, to replace callout
Andre Oppermann
andre at freebsd.org
Wed Jan 2 15:23:36 PST 2008
Robert Watson wrote:
>
> 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.
I fear we have to go for the latter. Getting a non-sleeping callout
drain seems to be non-trivial.
--
Andre
More information about the freebsd-arch
mailing list