From owner-freebsd-arch@FreeBSD.ORG Thu Aug 18 17:16:55 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BEA916A420; Thu, 18 Aug 2005 17:16:55 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09E7143D58; Thu, 18 Aug 2005 17:16:53 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 18 Aug 2005 13:31:54 -0400 From: John Baldwin To: Luigi Rizzo Date: Thu, 18 Aug 2005 13:12:20 -0400 User-Agent: KMail/1.8 References: <42F9ECF2.8080809@freebsd.org> <200508181023.05929.jhb@FreeBSD.org> <20050818095546.A91965@xorpc.icir.org> In-Reply-To: <20050818095546.A91965@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508181312.21512.jhb@FreeBSD.org> Cc: gnn@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Special schedulers, one CPU only kernel, one only userland 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: Thu, 18 Aug 2005 17:16:55 -0000 On Thursday 18 August 2005 12:55 pm, Luigi Rizzo wrote: > On Thu, Aug 18, 2005 at 10:23:04AM -0400, John Baldwin wrote: > ... > > > > However I am still unclear on what happens if a detach() is racing with > > > the output path (leading to fxp_start()). > > > > Note that we first down the interface via fxp_stop() and then we unhook > > it from the network stack using ether_ifdetach(). Once we've done > > ether_ifdetach() the network stack can't get to the fxp device anymore. > > It might have gotten there before, then this sequence might occur: > > thread 'fxp_detach' thread 'fxp_start' > > acquire fxp lock wait for lock (goes to sleep maybe ?) > fxp_stop > release fxp lock > destroy everything > including the lock > resume, mtx_lock -> boom > > hmmm... it's really tricky to follow. Maybe this does not happen, > but i wouldn't know why as fxp_detach() is under giant but the > path leading to fxp_start is not... ether_ifdetach() should be handling this for us I think by blocking until any known top-half threads are out of the driver. It may not be doing that yet, but I think that is where it should happen similar to how we use bus_teardown_intr() and callout_drain() in detach to block until other threads are out of our driver if necessary. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org