From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 23:23:34 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADF2E16A41B for ; Wed, 2 Jan 2008 23:23:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0663113C45A for ; Wed, 2 Jan 2008 23:23:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81600 invoked from network); 2 Jan 2008 22:48:49 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 22:48:49 -0000 Message-ID: <477C1CF3.6070301@freebsd.org> Date: Thu, 03 Jan 2008 00:23:31 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Robert Watson References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org> <20080102225534.U30578@fledge.watson.org> In-Reply-To: <20080102225534.U30578@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , arch@FreeBSD.org, Poul-Henning Kamp , John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 23:23:34 -0000 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