From jhb at FreeBSD.org  Thu Jan 29 07:59:05 2004
From: jhb at FreeBSD.org (John Baldwin)
Date: Tue Feb  3 22:48:28 2004
Subject: nasty device_delete_child interaction
In-Reply-To: <200401290635.i0T6ZO224579@jwlab.FEITH.COM>
References: <200401290635.i0T6ZO224579@jwlab.FEITH.COM>
Message-ID: <200401291050.40458.jhb@FreeBSD.org>

[ Moved this to new-bus@ list as that is more appropriate. ]

On Thursday 29 January 2004 01:35 am, John Wehle wrote:
> 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.
>
> It seems to me that any driver which calls device_delete_child
> as part of detaching must also implement something like:
>
>   xxx_child_detached()
>     {
>
>     if (child == sc->child_dev)
>       sc->child_dev = NULL;
>     }
>
>   xxx_detach()
>     {
>
>     /*
>      * Remember the child so we can delete it (bus_generic_detach
>      * indirectly zeroes sc->child_dev).
>      */
>     child = sc->child_dev;
>
>     bus_generic_detach();
>     if (child)
>       device_delete_child ...
>     }
>
> or am I missing something?
>
> -- John
> -------------------------------------------------------------------------
>
> |   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
> |    John Wehle    |     Fax: 1-215-540-5495  |                         |
>
> -------------------------------------------------------------------------

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org

From imp at bsdimp.com  Thu Jan 29 08:11:22 2004
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue Feb  3 22:59:14 2004
Subject: nasty device_delete_child interaction
In-Reply-To: <200401291050.40458.jhb@FreeBSD.org>
References: <200401290635.i0T6ZO224579@jwlab.FEITH.COM>
	<200401291050.40458.jhb@FreeBSD.org>
Message-ID: <20040129.091109.27780542.imp@bsdimp.com>

In message: <200401291050.40458.jhb@FreeBSD.org>
            John Baldwin <jhb@FreeBSD.org> writes:
: On Thursday 29 January 2004 01:35 am, John Wehle wrote:
: > 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 ...
: >     }

Don't do that.  You are duplicating the storage of children in two
places.  If you need to cache a copy of a child, that's fine.
However, don't delete it explicitly in xxx_detach.

I'd say that these drivers are wrong and should be fixed.

: > It seems to me that any driver which calls device_delete_child
: > as part of detaching must also implement something like:

No.  They should avoid the problem by using newbus correctly.  This
sort of solution just adds code to no good purpose.

Warner
From john at feith.com  Thu Jan 29 11:59:07 2004
From: john at feith.com (John Wehle)
Date: Wed Feb  4 02:23:34 2004
Subject: nasty device_delete_child interaction
Message-ID: <200401291959.i0TJx2m25103@jwlab.FEITH.COM>

A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1377 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-new-bus/attachments/20040129/1ed1df1f/attachment.ksh