Date: Thu, 03 Jan 2008 00:23:31 +0100 From: Andre Oppermann <andre@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Attilio Rao <attilio@FreeBSD.org>, arch@FreeBSD.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, John Baldwin <jhb@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: New "timeout" api, to replace callout Message-ID: <477C1CF3.6070301@freebsd.org> In-Reply-To: <20080102225534.U30578@fledge.watson.org> References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org> <20080102225534.U30578@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477C1CF3.6070301>