From: Alex Chiang <achiang@hp.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Xiaotian Feng <dfeng@redhat.com>,
lenb@kernel.org, bjorn.helgaas@hp.com, andrew.patterson@hp.com,
jbarnes@virtuousgeek.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] acpi: pci_root: fix NULL pointer deref after resume from suspend
Date: Mon, 28 Sep 2009 16:20:02 -0600 [thread overview]
Message-ID: <20090928222002.GC19406@ldl.fc.hp.com> (raw)
In-Reply-To: <200909282305.56102.rjw@sisk.pl>
* Rafael J. Wysocki <rjw@sisk.pl>:
> On Monday 28 September 2009, Rafael J. Wysocki wrote:
> > On Monday 28 September 2009, Alex Chiang wrote:
> > > * Xiaotian Feng <dfeng@redhat.com>:
> > > > --- a/drivers/acpi/pci_root.c
> > > > +++ b/drivers/acpi/pci_root.c
> > > > @@ -387,7 +387,11 @@ struct pci_dev *acpi_get_pci_dev(acpi_handle handle)
> > > > if (!pdev || hnd == handle)
> > > > break;
> > > >
> > > > - pbus = pdev->subordinate;
> > > > + if (pdev->subordinate)
> > > > + pbus = pdev->subordinate;
> > > > + else
> > > > + pbus = pdev->bus;
> > > > +
> > >
> > > I'm a little confused by this. If we start from the PCI root
> > > bridge and walk back down the hierarchy, shouldn't everything
> > > between the root and the device be a P2P bridge?
> >
> > Well, if my reading of the code is correct, there's no guarantee that
> > pci_get_slot() will always return either the right device or a bridge.
>
> I should have been more precise.
>
> If devfn of node happens to be the same as devfn of a non-bridge device on
> pbus, the pci_get_slot() will return a valid pointer to it, but
> pdev->subordinate will be NULL. Is it impossible for some reason?
Hm, that's a good thought, but I'm still confused. Here's the
first part of the full function (acpi_get_pci_dev):
phandle = handle;
while (!acpi_is_root_bridge(phandle)) {
node = kzalloc(sizeof(struct acpi_handle_node), GFP_KERNEL);
if (!node)
goto out;
INIT_LIST_HEAD(&node->node);
node->handle = phandle;
list_add(&node->node, &device_list);
status = acpi_get_parent(phandle, &phandle);
if (ACPI_FAILURE(status))
goto out;
}
phandle starts off as the input parameter, and we make successive
calls to acpi_get_parent() to walk up the ACPI device tree until
we get to a root bridge.
My assumption here is that all those ACPI devices must be P2P
bridges.
root = acpi_pci_find_root(phandle);
if (!root)
goto out;
pbus = root->bus;
Now we've got an acpi_pci_root() which has a struct pci_bus, and
we can start walking back down the PCI tree. Except what we're
really doing is iterating across the device_list which we created
above.
device_list should only contain P2P bridges, based on my
assumption above.
list_for_each_entry(node, &device_list, node) {
acpi_handle hnd = node->handle;
status = acpi_evaluate_integer(hnd, "_ADR", NULL, &adr);
if (ACPI_FAILURE(status))
goto out;
dev = (adr >> 16) & 0xffff;
fn = adr & 0xffff;
pdev = pci_get_slot(pbus, PCI_DEVFN(dev, fn));
if (!pdev || hnd == handle)
break;
pbus = pdev->subordinate;
pci_dev_put(pdev);
}
The point you raise about collision between the devfn of 'node'
and some non-bridge device returned by pci_get_slot() seems like
it really shouldn't happen, because we evaluate _ADR for each
node on device_list, in the reverse order that we found them, and
based on my assumption, all those nodes should be bridges.
I'm not saying that Xiaotian's patch is wrong. I'm saying I'd
like to be educated as to why my basic assumption was wrong,
because now you're making me think that this code is pretty
fragile. :-/
Thanks.
/ac
next prev parent reply other threads:[~2009-09-28 22:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-28 6:31 [PATCH] acpi: pci_root: fix NULL pointer deref after resume from suspend Xiaotian Feng
2009-09-28 17:38 ` Alex Chiang
2009-09-28 20:43 ` Rafael J. Wysocki
2009-09-28 21:05 ` Rafael J. Wysocki
2009-09-28 22:20 ` Alex Chiang [this message]
2009-09-28 22:50 ` Rafael J. Wysocki
2009-09-29 10:11 ` Danny Feng
2009-09-29 20:08 ` Rafael J. Wysocki
2009-09-29 20:49 ` Alex Chiang
2009-09-29 23:31 ` Rafael J. Wysocki
2009-09-29 1:44 ` Danny Feng
2009-09-29 20:12 ` Rafael J. Wysocki
2009-09-30 2:46 ` Danny Feng
2009-09-30 21:26 ` Rafael J. Wysocki
2009-10-01 20:05 ` Alex Chiang
2009-10-03 22:56 ` Rafael J. Wysocki
2009-10-09 1:17 ` Danny Feng
2009-10-09 2:26 ` Danny Feng
2009-10-09 21:46 ` Rafael J. Wysocki
2009-10-12 3:05 ` Danny Feng
2009-10-09 1:16 ` Danny Feng
2009-10-09 2:28 ` Danny Feng
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=20090928222002.GC19406@ldl.fc.hp.com \
--to=achiang@hp.com \
--cc=andrew.patterson@hp.com \
--cc=bjorn.helgaas@hp.com \
--cc=dfeng@redhat.com \
--cc=jbarnes@virtuousgeek.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
/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