From: Jiang Liu <email@example.com>
To: Bjorn Helgaas <firstname.lastname@example.org>
Cc: Taku Izumi <email@example.com>,
Subject: Re: [PATCH v2 4/6] ACPI, PCI: add acpi_pci_roots protection
Date: Sat, 15 Sep 2012 11:23:51 +0800 [thread overview]
Message-ID: <5053F4C7.firstname.lastname@example.org> (raw)
On 09/14/2012 10:43 PM, Bjorn Helgaas wrote:
> On Thu, Sep 13, 2012 at 10:35 PM, Taku Izumi <email@example.com> wrote:
>> On Wed, 12 Sep 2012 17:40:45 -0600
>> Bjorn Helgaas <firstname.lastname@example.org> wrote:
>>> On Mon, Sep 3, 2012 at 2:06 AM, Taku Izumi <email@example.com> wrote:
>>>> Use mutex and RCU to protect global acpi_pci_roots list against
>>>> PCI host bridge hotplug operations.
>>>> RCU is used to avoid possible deadlock in function acpi_pci_find_root()
>>>> and acpi_get_pci_rootbridge_handle(). A possible call graph:
>>> Where does this path occur? I didn't see in in the current tree
>>> (where the only users of acpi_pci_register_driver() are for
>>> acpi_pci_slot_driver and acpi_pci_hp_driver). Maybe it's in Yinghai's
>>> work, which adds more acpi_pci_register_driver() users.
>> First I protected acpi_pci_roots list by using mutex(acpi_pci_root_lock).
>> In that case I faced deadlock at the following path:
>> + acpi_pci_register_driver
>> + add_bridge
>> + acpi_pci_find_root
>> So I used RCU instead.
> Oh, right. I missed the acpiphp_glue_init() path. That's clearly a problem.
It's amazing. When I was writing the code, I just realized there's a possible
deadlock scenario and then wrote defensive code. Not it's proven to be true:)
>>> RCU seems unnecessarily complicated for this list, but I haven't gone
>>> through Yinghai's work yet, so I don't know what it requires.
>>> In acpi_pci_root_start() and acpi_pci_root_remove(), we have the
>>> struct acpi_pci_root, which has all sorts of information that would be
>>> useful to the .add() and .remove() methods of sub-drivers. It seems
>>> sort of stupid that we only pass the acpi_handle to the sub-drivers,
>>> forcing them to use hacks like acpi_pci_find_root() to look up the
>>> information we just threw away. Can we just fix the .add() and
>>> .remove() interfaces to pass something more useful so we avoid the
>>> need for this deadlock path?
>> Maybe yes. Do you prefer imprementation without RCU ?
> Yes, if it's possible, I prefer to avoid RCU in this case. RCU is
> appropriate for performance paths, but it's much more difficult to
> analyze than mutex locking.
> Host bridge hotplug is definitely not a path where performance is an
> issue, and I think reworking the .add()/.remove() interfaces will
> allow us to use mutex locking.
> I think it will also simplify the sub-drivers because having the
> struct acpi_pci_root means they can get rid of acpi_pci_find_root(),
> they don't have to re-evaluate _SEG and _BBN (in acpi_pci_slot_add()
> -> walk_root_bridge()), they don't have to use pci_find_bus(), etc.
Yes, it would be better to get rid of the RCU staff.
next prev parent reply other threads:[~2012-09-15 3:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-03 7:58 [PATCH v2 0/6] acpi,pci: hostbridge hotplug support Taku Izumi
2012-09-03 8:03 ` [PATCH v2 1/6] ACPI, PCI: Use normal list for struct acpi_pci_driver Taku Izumi
2012-09-03 8:04 ` [PATCH v2 2/6] ACPI, PCI: Notify acpi_pci_drivers when hot-plugging PCI root bridges Taku Izumi
2012-09-04 7:58 ` Kaneshige, Kenji
2012-09-04 19:12 ` Yinghai Lu
2012-09-05 4:32 ` Kaneshige, Kenji
2012-09-05 5:01 ` Yinghai Lu
2012-09-05 8:55 ` Kaneshige, Kenji
2012-09-03 8:05 ` [PATCH v2 3/6] ACPI, PCI: add acpi_pci_drivers protection Taku Izumi
2012-09-03 8:06 ` [PATCH v2 4/6] ACPI, PCI: add acpi_pci_roots protection Taku Izumi
2012-09-12 23:40 ` Bjorn Helgaas
2012-09-13 19:09 ` Yinghai Lu
2012-09-13 19:39 ` Bjorn Helgaas
2012-09-13 21:17 ` Yinghai Lu
2012-09-13 22:44 ` Yinghai Lu
2012-09-14 4:35 ` Taku Izumi
2012-09-14 14:43 ` Bjorn Helgaas
2012-09-15 3:23 ` Jiang Liu [this message]
2012-09-03 8:06 ` [PATCH v2 5/6] ACPI, PCI: add hostbridge removal function Taku Izumi
2012-09-03 8:07 ` [PATCH v2 6/6] ACPI, PCI: add resoruce-assign code for devices under hot-added hostbridge Taku Izumi
2012-09-03 20:27 ` Yinghai Lu
2012-09-07 9:26 ` Taku Izumi
2012-09-07 9:31 ` Taku Izumi
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).