From owner-freebsd-arch@FreeBSD.ORG Thu Aug 18 18:56:12 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 787E116A41F; Thu, 18 Aug 2005 18:56:12 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BAF343D45; Thu, 18 Aug 2005 18:56:11 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j7IIuB0h094300; Thu, 18 Aug 2005 11:56:11 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j7IIuBU2094299; Thu, 18 Aug 2005 11:56:11 -0700 (PDT) (envelope-from rizzo) Date: Thu, 18 Aug 2005 11:56:11 -0700 From: Luigi Rizzo To: John Baldwin Message-ID: <20050818115611.A94148@xorpc.icir.org> References: <42F9ECF2.8080809@freebsd.org> <200508181023.05929.jhb@FreeBSD.org> <20050818095546.A91965@xorpc.icir.org> <200508181312.21512.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200508181312.21512.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Thu, Aug 18, 2005 at 01:12:20PM -0400 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 18:56:12 -0000 On Thu, Aug 18, 2005 at 01:12:20PM -0400, John Baldwin wrote: [discussion about potential race between foo_detach() and foo_start()] > > 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, ok but note that fxp_start could well be called by a bottom-half thread receiving from a different interface and forwarding to this one. In any case the detach is probably a very difficult part to fix because there are references to interfaces all over the place, and they are not refcounted so we can never know when it is safe to release memory. At least, so i believe... cheers luigi