Date: Tue, 25 Mar 2003 09:04:34 +0700 (ICT) From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: "M. Warner Losh" <imp@bsdimp.com> Cc: mdodd@FreeBSD.ORG, <dfr@FreeBSD.ORG>, <hackers@FreeBSD.ORG> Subject: Re: bug in subr_bus.c? Message-ID: <20030325085519.I97066-100000@resnet.uoregon.edu> In-Reply-To: <20030323.092305.83978540.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Mar 2003, M. Warner Losh wrote: > In message: <20030323174445.K36261-100000@resnet.uoregon.edu> > John-Mark Gurney <gurney_j@resnet.uoregon.edu> writes: > : The bus code could use some locking in it... like you can't delete_child > : from child_detache... and/or better docs on how to handle children... I'm > : not even sure how I was doing things wrong, but I think it might of been > : problems with my code not calling bus_generic_detach before calling > : device_child_delete... > > I'm doing the locking, but you can do a bus_delete_child in a child's > detach routine. Cardbus does this right now and it works when you > unload the cardbus bridge... (btw, I'm using 1.117.2.1 as reference 5.0-R) I'm talking about child_detached (I forgot the d), not detach... so, say you have a bus driver that has a child_detached routine. When you unload the kld for the child, the kld will do a detach of the child. If you look at the device_detach, it will call the device's detach, then the parent's child_detached routine all before marking the device as NOTPRESENT. If you try to do a device_delete_child in the child_detached routine, device_delete_child will call device_detach again, and since the state is still ATTACHED, it will go through the detach procedure again, and either end up with a memory fault or a recursive loop. I just looked briefly at the cardbus code, and you don't have a child_detached routine. John-Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030325085519.I97066-100000>