From owner-cvs-all  Wed Jan 15 16:29:58 2003
Delivered-To: cvs-all@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id F1DA037B401; Wed, 15 Jan 2003 16:29:56 -0800 (PST)
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id A6C3B43F13; Wed, 15 Jan 2003 16:29:56 -0800 (PST)
	(envelope-from davidxu@FreeBSD.org)
Received: from freefall.freebsd.org (davidxu@localhost [127.0.0.1])
	by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h0G0TuNS099626;
	Wed, 15 Jan 2003 16:29:56 -0800 (PST)
	(envelope-from davidxu@freefall.freebsd.org)
Received: (from davidxu@localhost)
	by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h0G0To0o099625;
	Wed, 15 Jan 2003 16:29:50 -0800 (PST)
Date: Wed, 15 Jan 2003 16:29:50 -0800 (PST)
From: David Xu <davidxu@FreeBSD.org>
Message-Id: <200301160029.h0G0To0o099625@freefall.freebsd.org>
To: Nate Lawson <nate@root.org>
Subject: Re: cvs commit: src/sys/kern subr_bus.c
Cc: "cvs-all@FreeBSD.org" <cvs-all@FreeBSD.org>,
	cvs-committers@FreeBSD.org
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG


----- Original Message ----- 
From: "Nate Lawson" <nate@root.org>
To: "David Xu" <davidxu@FreeBSD.org>
Cc: <cvs-all@FreeBSD.org>; <cvs-committers@FreeBSD.org>
Sent: Thursday, January 16, 2003 2:16 AM
Subject: Re: cvs commit: src/sys/kern subr_bus.c


> On Wed, 15 Jan 2003, David Xu wrote:
> >   Modified files:
> >     sys/kern             subr_bus.c 
> >   Log:
> >   Don't forget to disconnect object from class.
> >   
> >   Revision  Changes    Path
> >   1.121     +3 -2      src/sys/kern/subr_bus.c
> 
> Does this fix the memory leak when loading/unloading a module many
> times?  I've seen indications that there was one but haven't tracked it
> down farther.
> 
> -Nate

In device_delete_child, this fixed nullclass reference count.
because the class is always in memory and already compiled,
there is no memory leak. 
 
Only in device_set_driver, if system is out of memory, it would
cause memory leak. but at that time, I don't think the system will
continue running, it would panic in other places.
So these are nits.

David


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message