public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Dobson <colpatch@us.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: rmk@arm.linux.org.uk, Greg KH <gregkh@us.ibm.com>
Subject: [BUG/MEMLEAK?] struct pci_bus, child busses & bridges
Date: Wed, 24 Sep 2003 17:34:03 -0700	[thread overview]
Message-ID: <3F7237FB.8050509@us.ibm.com> (raw)

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


             reply	other threads:[~2003-09-25  0:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-25  0:34 Matthew Dobson [this message]
2003-09-25  8:54 ` [BUG/MEMLEAK?] struct pci_bus, child busses & bridges Russell King
2003-09-25 18:14   ` Matthew Dobson
2003-09-25 18:53     ` Patrick Mochel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F7237FB.8050509@us.ibm.com \
    --to=colpatch@us.ibm.com \
    --cc=gregkh@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox