[lkml]   [2003]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BUG/MEMLEAK?] struct pci_bus, child busses & bridges
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?



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:48    [W:0.048 / U:3.440 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site