From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 22:56:21 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27A0916A41A; Wed, 2 Jan 2008 22:56:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id D83E213C442; Wed, 2 Jan 2008 22:56:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B97DA486D8; Wed, 2 Jan 2008 17:56:19 -0500 (EST) Date: Wed, 2 Jan 2008 22:56:19 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <477C1604.2030905@freebsd.org> Message-ID: <20080102225534.U30578@fledge.watson.org> References: <18378.1196596684@critter.freebsd.dk> <4752AABE.6090006@freebsd.org> <200712271805.40972.jhb@freebsd.org> <477C1604.2030905@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 22:56:21 -0000 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