This is a discussion on [PATCH v5 00/16] PCI: let the core manage slot names - Kernel ; * Kenji Kaneshige : > Alex Chiang wrote: >> Ugh, I'm not sure which is worse, an unbalanced API vs passing a >> hotplug_slot to pci_destroy_slot. >> >> pci_destroy_slot should never touch the pci_slot->hotplug >> argument, I think, because it ...
* Kenji Kaneshige
> Alex Chiang wrote:
>> Ugh, I'm not sure which is worse, an unbalanced API vs passing a
>> hotplug_slot to pci_destroy_slot.
>> pci_destroy_slot should never touch the pci_slot->hotplug
>> argument, I think, because it is possible for non-hotplug callers
>> to call pci_create_slot.
>> I think the rule should just be:
>> - all hotplug drivers must use pci_hp_register/deregister
>> - hotplug drivers must pass a valid hotplug_slot argument
>> - all detection drivers must use pci_create/destroy_slot
>> - detection drivers must pass NULL for hotplug_slot
> I'm still concerned about one thing. Now that we added hotplug
> arg to pci_create_slot(), pci_bus_sem could be used for changing
> pci_slot->hotplug. But if there is no generic API to clean up
> pci_slot->hotplug, we can't use pci_bus_sem because pci hotplug
> core cannot hold pci_bus_sem. As a result, we need to add the
> following rule in addition to the above rules.
> - hotplug core driver must hold some mutex/semaphore when
> calling pci_create_slot()
> - hotplug core driver must hold the same mutex/semaphore
> when cleaning up pci_slot->hotplug.
> That is, even though pci_create_slot provides the interface to
> setup pci_slot->hotplug, caller needs to pay attention to race
> condition about pci_slot->hotplug. I think it's a little strange.
I think we can use your earlier patch that replaced the hotplug
list spinlock with a pci_hp_mutex, and that should implement the
two new rules you mention, right?
Let me try and insert your patch into the rest of my series and
see how it looks.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/