Date: Mon, 9 Feb 2004 13:03:04 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: John Wehle <john@feith.com> Cc: current@freebsd.org Subject: Re: nasty device_delete_child interaction Message-ID: <20040209210304.GF85686@funkthat.com> In-Reply-To: <200401290635.i0T6ZO224579@jwlab.FEITH.COM> References: <200401290635.i0T6ZO224579@jwlab.FEITH.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
John Wehle wrote this message on Thu, Jan 29, 2004 at 01:35 -0500:
> device_delete_child works by starting with the grandchildren
> working back towards the immediate child. Several drivers
> (i.e. if_xl.c, if_wx.c, iicbb.c) have code similar to:
>
> xxx_attach()
> {
>
> ...
> sc->child_dev = device_add_child ...
> }
>
> xxx_detach()
> {
>
> bus_generic_detach ();
> if (sc->child_dev)
> device_delete_child ...
> }
>
> The problem is using device_delete_child on one of these
> drivers causes the grandchild to be freed twice. When
> device_delete_child is called for xxx, it recurses since
> xxx has a child. The grandchild is detached and deleted.
> xxx_detach is then called which calls device_delete_child
> for the grandchild a second time causing a panic.
Yes, I know about this problem. One of the problems with this also is
that the newbus code isn't properly locked, nor are ref counts kept
on who has a pointer, so that as device_delete_child happen, you can
easily end up accessing a free'd device as you point out...
There are many issues with the code, if you are interested in fixing
these, drop me an email and I'll tell you more about them.
I ran into these issues myself when writing my Zoran driver and working
with the iicbus code.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040209210304.GF85686>