On Thu, Sep 13, 2012 at 1:09 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Wed, Sep 12, 2012 at 4:40 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Mon, Sep 3, 2012 at 2:06 AM, Taku Izumi <izumi.taku@xxxxxxxxxxxxxx> 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: >>> acpi_pci_register_driver() >>> mutex_lock(&acpi_pci_root_lock) >>> driver->add(root) >>> ...... >>> acpi_pci_find_root() >> >> 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. >> >> 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? > > new added acpi_pci_driver for ioapic, and iommu does not call > acpi_pci_find_root(). > > after split out pci_root_hp.c from acpiphp_glue.c, there will be > acpi_root_configure_bridge in pci_root_hp.c. that one could be > converted to > passing device instead of handle. If I understand you correctly, you're agreeing that if we change the .add()/.remove() interfaces, there is no need for RCU here. Correct me if I'm wrong. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
