* Kenji Kaneshige <kaneshige.kenji@xxxxxxxxxxxxxx>: > 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. /ac -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
