Re: [BUG/MEMLEAK?] struct pci_bus, child busses & bridges

[Matthew Dobson]

Russell King wrote:
> On Wed, Sep 24, 2003 at 05:34:03PM -0700, Matthew Dobson wrote:
>
> > In pci_alloc_child_bus (drivers/pci/probe.c), the child bus is allocated 
> > and it's struct dev * is set to point to the struct dev belonging to the 
> > bridge that this bus is 'on', or 'behind'.  pci_alloc_child_bus is 
> > called in 3 places: pci_add_new_bus and twice in pci_scan_bridge.  The 
> > calls in pci_scan_bridge allocate a new struct pci_bus, but then seem to 
> > throw the references away, *without* freeing them.
>
>
> That is correct - they persist after they have been allocated until the
> bridge device is destroyed (if ever) - it's lifetime is directly equivalent
> to the lifetime of the bridge.
>
> If you look carefully at pci_alloc_child_bus(), you will notice that
> bridge->subordinate is setup to point at the pci_bus, which provides
> a method to access the data held in the pci_bus later (eg, while we're
> freeing the structures.)

Ok, I see that now.  I guess my only remaining question is why do child 
busses not get their own struct device, but rather only a pointer to the 
bridge's struct device?  There's no refcounting done on this, ie: no 
pci_dev_get/put calls, but I guess that's kinda ok, since we're pretty 
sure that the child bus won't exist for longer than the bridge that owns 
it, right?  So using the bridge's struct dev allows the pci topology to 
look cleaner?  As in, there's no actual bus exposed in sysfs/procfs/etc, 
just devices that seem to be hanging off the bridge?

Cheers!

-Matt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/