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

[Matthew Dobson]

Whilst working on what was supposed to be a fairly trivial patch, I 
stumbled across what looks to be a relatively significant bug in the way 
pci bridges are handled.  I could easily be wrong, as the pci code is 
far from anything I'd be willing to call an area of expertise.  That 
said, my description of the problem follows:

I am trying to add a file to the pci bus (ie: /sysfs/devices/pciXXXX:XX) 
directories in sysfs.  This led to the discovery that struct pci_bus 
(inlude/linux/pci.h) does not have an *actual* struct dev inside it, 
rather a pointer to a struct dev.  I found this interesting, as most 
device-type-thingies have an honest to goodness struct dev, allowing the 
use of container_of(), etc.  A quick perusal of the code offered no 
reason why struct pci_bus couldn't be changed to have the actual struct 
dev inside it, saving us kmalloc'ing and kfree'ing these, and generally 
keeping track of them.  I was wrong.

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.

It appears that these pseudo-busses are allocated and used as a kind of 
hack, to allow devices to be parented to pci bridge devices.  The 
pci_dev for the bridge is allocated and initialized, then a child bus is 
created, and it's *dev is pointed to the struct device belonging to the 
pci bridge.  There are no refcounts used for this, and it doesn't appear 
to be cleaned up in any way.  If anyone can offer any insight into this 
problem, or show me why I'm wrong, it would be greatly appreciated.

Thanks!

-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/