From: Jiang Liu <liuj97@gmail.com>
To: Amos Kong <akong@redhat.com>
Cc: mst@redhat.com, linux-pci@vger.kernel.org, seabios@seabios.org,
qemu-devel@nongnu.org, jbarnes@virtuousgeek.org,
alex.williamson@redhat.com, kevin@koconnor.net
Subject: Re: [PATCH v3] pci: clean all funcs when hot-removing multifunc device
Date: Fri, 11 May 2012 01:09:13 +0800 [thread overview]
Message-ID: <4FABF639.4070205@gmail.com> (raw)
In-Reply-To: <20120510154423.11306.85353.stgit@t>
On 05/10/2012 11:44 PM, Amos Kong wrote:
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
> index 806c44f..a7442d9 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -885,7 +885,7 @@ static void disable_bridges(struct pci_bus *bus)
> static int disable_device(struct acpiphp_slot *slot)
> {
> struct acpiphp_func *func;
> - struct pci_dev *pdev;
> + struct pci_dev *pdev, *tmp;
> struct pci_bus *bus = slot->bridge->pci_bus;
>
> /* The slot will be enabled when func 0 is added, so check
> @@ -902,9 +902,10 @@ static int disable_device(struct acpiphp_slot *slot)
> func->bridge = NULL;
> }
>
> - pdev = pci_get_slot(slot->bridge->pci_bus,
> - PCI_DEVFN(slot->device, func->function));
> - if (pdev) {
> + list_for_each_entry_safe(pdev, tmp, &bus->devices, bus_list) {
> + if (PCI_SLOT(pdev->devfn) != slot->device)
> + continue;
> +
The pci_bus_sem lock should be acquired when walking the bus->devices list.
Otherwise it may cause invalid memory access if another thread is modifying
the bus->devices list concurrently.
BTW, what's the relationship with "[PATCH v3] hotplug: add device per func
in ACPI DSDT tables"? Seems they are both solving the same issue.
> pci_stop_bus_device(pdev);
> if (pdev->subordinate) {
> disable_bridges(pdev->subordinate);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Jiang Liu <liuj97@gmail.com>
To: Amos Kong <akong@redhat.com>
Cc: mst@redhat.com, linux-pci@vger.kernel.org, seabios@seabios.org,
qemu-devel@nongnu.org, jbarnes@virtuousgeek.org,
alex.williamson@redhat.com, kevin@koconnor.net
Subject: Re: [Qemu-devel] [PATCH v3] pci: clean all funcs when hot-removing multifunc device
Date: Fri, 11 May 2012 01:09:13 +0800 [thread overview]
Message-ID: <4FABF639.4070205@gmail.com> (raw)
In-Reply-To: <20120510154423.11306.85353.stgit@t>
On 05/10/2012 11:44 PM, Amos Kong wrote:
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
> index 806c44f..a7442d9 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -885,7 +885,7 @@ static void disable_bridges(struct pci_bus *bus)
> static int disable_device(struct acpiphp_slot *slot)
> {
> struct acpiphp_func *func;
> - struct pci_dev *pdev;
> + struct pci_dev *pdev, *tmp;
> struct pci_bus *bus = slot->bridge->pci_bus;
>
> /* The slot will be enabled when func 0 is added, so check
> @@ -902,9 +902,10 @@ static int disable_device(struct acpiphp_slot *slot)
> func->bridge = NULL;
> }
>
> - pdev = pci_get_slot(slot->bridge->pci_bus,
> - PCI_DEVFN(slot->device, func->function));
> - if (pdev) {
> + list_for_each_entry_safe(pdev, tmp, &bus->devices, bus_list) {
> + if (PCI_SLOT(pdev->devfn) != slot->device)
> + continue;
> +
The pci_bus_sem lock should be acquired when walking the bus->devices list.
Otherwise it may cause invalid memory access if another thread is modifying
the bus->devices list concurrently.
BTW, what's the relationship with "[PATCH v3] hotplug: add device per func
in ACPI DSDT tables"? Seems they are both solving the same issue.
> pci_stop_bus_device(pdev);
> if (pdev->subordinate) {
> disable_bridges(pdev->subordinate);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-05-10 17:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1315976141-6684-1-git-send-email-akong@redhat.com>
2011-09-14 4:56 ` [PATCH] pci: clean all funcs when hot-removing multifunc device Amos Kong
2011-09-15 19:03 ` Bjorn Helgaas
2011-09-15 23:56 ` Kenji Kaneshige
2012-05-09 15:25 ` [PATCH v2] " Amos Kong
2012-05-09 15:25 ` [Qemu-devel] " Amos Kong
2012-05-10 15:44 ` [PATCH v3] " Amos Kong
2012-05-10 15:44 ` [Qemu-devel] " Amos Kong
2012-05-10 17:09 ` Jiang Liu [this message]
2012-05-10 17:09 ` Jiang Liu
2012-05-10 18:55 ` Michael S. Tsirkin
2012-05-10 18:55 ` [Qemu-devel] " Michael S. Tsirkin
2012-05-10 23:54 ` Amos Kong
2012-05-10 23:54 ` Amos Kong
2012-05-11 0:24 ` Amos Kong
2012-05-11 0:24 ` Amos Kong
2012-05-11 14:00 ` Jiang Liu
2012-05-16 15:26 ` Bjorn Helgaas
2012-05-16 15:26 ` Bjorn Helgaas
2012-05-20 2:31 ` [PATCH v4] " kongjianjun
2012-05-20 2:31 ` [Qemu-devel] " kongjianjun
2012-05-20 2:36 ` [Qemu-devel] [PATCH v3] " Amos Kong
2012-05-20 2:36 ` Amos Kong
2012-05-20 2:59 ` [PATCH v5] " kongjianjun
2012-05-20 2:59 ` [Qemu-devel] " kongjianjun
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=4FABF639.4070205@gmail.com \
--to=liuj97@gmail.com \
--cc=akong@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=jbarnes@virtuousgeek.org \
--cc=kevin@koconnor.net \
--cc=linux-pci@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.