From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 22:57:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63BC916A614 for ; Mon, 23 Jan 2006 22:57:38 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D2D24427E for ; Mon, 23 Jan 2006 22:38:20 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6795869 for multiple; Mon, 23 Jan 2006 17:39:22 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0NMcBQa003976; Mon, 23 Jan 2006 17:38:12 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Peter Jeremy Date: Mon, 23 Jan 2006 17:36:01 -0500 User-Agent: KMail/1.9.1 References: <20060121070706.GA32444@cirb503493.alcatel.com.au> <200601231618.04949.jhb@freebsd.org> <20060123214151.GO25397@cirb503493.alcatel.com.au> In-Reply-To: <20060123214151.GO25397@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601231736.03028.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1247/Sat Jan 21 05:24:51 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org Subject: Re: Panic due to deleting devices twice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 22:57:53 -0000 On Monday 23 January 2006 16:41, Peter Jeremy wrote: > On Mon, 2006-Jan-23 16:18:03 -0500, John Baldwin wrote: > >On Saturday 21 January 2006 02:07, Peter Jeremy wrote: > >> Looking at the iicsmb code, it appears that iicbb and iicsmb both > >> cache and explicitly delete child devices and therefore both need > >> bus_child_detached methods. Is this correct? Is there a simpler > >> alternative? > > > >Can they just call bus_generic_detach() instead and not call > >device_delete_child()? > > The existing code does both: > > static int iicbb_detach(device_t dev) > { > struct iicbb_softc *sc = (struct iicbb_softc > *)device_get_softc(dev); > > if (sc->iicbus) { > bus_generic_detach(dev); > device_delete_child(dev, sc->iicbus); > } > > return (0); > } > > static int > iicsmb_detach(device_t dev) > { > struct iicsmb_softc *sc = (struct iicsmb_softc > *)device_get_softc(dev); > > bus_generic_detach(dev); > if (sc->smbus) { > device_delete_child(dev, sc->smbus); > } > > return (0); > } > > Maybe a better solution in both cases is to just map device_detach to > bus_generic_detach() - in which case my patch in kern/92092 is overly > baroque. I was hoping that someone might shed some insight into why > it was done that way in the first case. Yeah, they should probably just use bus_generic_detach(), and they probably don't even need the smbus and iicbus pointers in their softc for that matter. Well, that might not be true. I think some of the drivers that use device_delete_child() only use the pointer to call that function, but some drivers use child devices to handle requests (smb comes to mind IIRC). If the drivers in question just use the device_t so they can call device_delete_child(), then I think you can axe the member from the softc and just use bus_generic_detach(). If they use the reference for other things, then the bus_device_detached route as in your patch in the PR is the way to go. This is assuming that this is a device whose parent will delete it when it is detached (this is true for many 'psuedo-bus' devices like smb). If a device isn't like that, then it may need to always use a bus_device_detached hook and call device_delete_child() conditionally in its detach routine. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org