Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jun 2013 22:43:35 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Warner Losh <imp@freebsd.org>, new-bus@freebsd.org
Subject:   Re: [PATCH] Change the PCI bus driver to free resources leaked by drivers
Message-ID:  <9886E26E-767F-4136-9A42-B7E38DBFE170@bsdimp.com>
In-Reply-To: <201306241659.15119.jhb@freebsd.org>
References:  <201306241659.15119.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Jun 24, 2013, at 2:59 PM, John Baldwin wrote:

> Currently our driver model trusts drivers to DTRT and properly release =
any=20
> resources they allocated during probe() and attach().  I've added a =
new
> resource_list() helper method to release active resources on a =
resource
> list and used this to write a pci_child_detached() which cleans up any
> active resources when a device fails to probe or a driver finishes
> detach.  It also fixes an issue where we did not power down devices =
when
> the driver was detached (e.g. via kldunload).  I've tested the =
resource
> bits by writing a dummy driver that intentionally attached to an =
unattached
> device and leaked a memory BAR and verified that the bus warned about =
the
> leak and cleaned it up.
>=20
> http://www.FreeBSD.org/~jhb/patches/pci_clean_detach.patch

I think most of pci_child_detached() could be a generic thing (except =
for the weird interaction with the msi-wart).  This is likely fixable.

We don't tear down any interrupt handlers that the device established. =
This is fixable, but the PCI bus would need to start tracking interrupts =
that are established...

We don't tear down any timers the device may have setup. This likely =
isn't fixable.

We likely don't want to tear down interrupts in bus_deactivate_resource, =
since I think it is theoretically legal to deactivate an interrupt =
resource without tearing down the interrupt. But maybe it shouldn't =
be...

Warner





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9886E26E-767F-4136-9A42-B7E38DBFE170>