Date: Wed, 2 Jan 2008 22:56:19 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Andre Oppermann <andre@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: <20080102225534.U30578@fledge.watson.org> In-Reply-To: <477C1604.2030905@freebsd.org> References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080102225534.U30578>