From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 9 12:22:52 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AE5716A4E7 for ; Wed, 9 Aug 2006 12:22:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12CA543D4C for ; Wed, 9 Aug 2006 12:22:50 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k79CMehk060174; Wed, 9 Aug 2006 08:22:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 9 Aug 2006 08:15:30 -0400 User-Agent: KMail/1.9.1 References: <200608021437.55500.hselasky@c2i.net> <20060809.000719.-432838874.imp@bsdimp.com> <200608091022.02584.hselasky@c2i.net> In-Reply-To: <200608091022.02584.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608090815.31152.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Wed, 09 Aug 2006 08:22:41 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1641/Tue Aug 8 19:01:19 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Hans Petter Selasky Subject: Re: miibus + USB = problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2006 12:22:52 -0000 On Wednesday 09 August 2006 04:22, Hans Petter Selasky wrote: > > The aue driver takes out the AUE_LOCK in these routines, and in > > detach, it unregisters the timeout. Alas, it is stupid, and does this > > with the lock held, thus ensuring deadlock if the timeout fires after > > the lock is acquired, but before the untimeout can complete (meaning > > that the timeout routine would sleep forever waiting for the lock, > > oops). This is why you can't run the detach routine locked in most > > cases. > > Yes, all of that is gone now. I use "callout_init_mtx()" and that solves the > problem, except it does not wait for the last mtx_lock()/mtx_unlock(), in > case of a race :-( > > You need to hold a lock during detach. Else you can risk that the callbacks > will re-start functions you have already shut down, like USB transfers, and > then you never get detached. This is the model that other drivers follow: FOO_LOCK(sc); foo_stop(sc); FOO_UNLOCK(sc); callout_drain(...); taskqueue_drain(...); bus_teardown_intr(...); ether_ifdetach(...); in foo_lock() you do things like a callout_stop() with the lock held and disable interrupts from the device. You can also mark it as dying, etc. in that function. Then after you drop the lock you perform several operations to wait for any other threads that might be in the driver to be out of the driver. callout_drain() should be called on each callout. If you have any task's, call taskqueue_drain() on those. bus_teardown_intr() won't return until your handler is both deregistered and finished executing if it was currently in progress. ether_ifdetach() should guarantee that any other threads coming into your driver via the if_*() routines are all gone. (This last one doesn't actually do that yet, but eventually it will, and other drivers depend on it to do so.. that is a problem to be solved in the ifnet layer, not in your driver.) -- John Baldwin