From owner-freebsd-hackers@FreeBSD.ORG Thu May 31 16:28:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 592BF106564A; Thu, 31 May 2012 16:28:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EA2918FC0A; Thu, 31 May 2012 16:28:12 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4VGFrIa060641 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 10:15:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201205311154.15062.jhb@freebsd.org> Date: Thu, 31 May 2012 10:15:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2A30119B-0C5E-43A9-9B26-11FCF6685999@bsdimp.com> References: <4FC729A2.30205@demig.de> <201205311154.15062.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 31 May 2012 10:15:55 -0600 (MDT) Cc: Norbert Koch , freebsd-hackers@freebsd.org, Warner Losh Subject: Re: bus device/ivars 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: Thu, 31 May 2012 16:28:13 -0000 On May 31, 2012, at 9:54 AM, John Baldwin wrote: > On Thursday, May 31, 2012 4:19:46 am Norbert Koch wrote: >> Hello, >>=20 >> I have written a bus device driver >> which itself is a pci driver. Child devices >> may allocate resources from my bus device. >>=20 >> My bus device does the usual >> management of resources through >> the children's ivars. >>=20 >> My question is this: >>=20 >> The bus device mallocs the >> children's ivars in bus_add_child >> and frees the ivars in either >> bus_detach or bus_child_detached. >>=20 >> The children are added in identify >> methods through BUS_ADD_CHILD. >>=20 >> As I understand the code the bus device's >> bus_child_detached method is called >> in device_delete_child only if >> the child device is already attached. >>=20 >> So, there seems to be a memory leak if >> I delete the child device in either >> identify or probe. >>=20 >> My current solution (not tested yet) is to >> explicitly call BUS_CHILD_DETACHED >> in the child device's code before >> calling device_delete_child. >>=20 >> Is this the correct way or is >> there a more elegant/cleaner solution? >>=20 >> I expected to find something like a >> BUS_DELETE_CHILD method. >=20 > We should perhaps have a BUS_CHILD_DELETED? I think that would do = what you=20 > want. We could maybe add a BUS_DELETE_CHILD(), but it would be = assymmetric to=20 > have device_delete_child() call BUS_DELETE_CHILD() when = device_add_child()=20 > does not call BUS_ADD_CHILD(). (Instead, BUS_ADD_CHILD() calls=20 > device_add_child, which is perhaps wrong.) >=20 > For now I would change your child code to call a wrapper = foo_delete_child()=20 > function from your child drivers directly rather than calling=20 > device_delete_child(). foo_delete_child() can do its cleanup and = then call=20 > device_delete_child(). We likely should have a BUS_CHILD_DELETED function that can get called = for each class in the stack when a child is deleted so you can remove = the ivars. The ivars should likely stay around when the device is = merely detached. Warner