On Tue, Mar 24, 2020 at 05:15:34PM +0100, Lukas Wunner wrote:
> The pci_dev_trylock() in pci_try_reset_function() looks questionable
> to me. It was added by commit b014e96d1abb ("PCI: Protect
> pci_error_handlers->reset_notify() usage with device_lock()")
> with the following rationale:
>
> Every method in struct device_driver or structures derived from it like
> struct pci_driver MUST provide exclusion vs the driver's ->remove()
> method, usually by using device_lock().
> [...]
> Without this, ->reset_notify() may race with ->remove() calls, which
> can be easily triggered in NVMe.
>
> The intersection of drivers defining a ->reset_notify() hook and files
> invoking pci_try_reset_function() appears to be empty. So I don't quite
> understand the problem the commit sought to address. What am I missing?
No driver defines ->reset_notify as that has been split into
->reset_prepare and ->reset_done a while ago, and plenty of drivers
define those. And we can't call into drivers unless we know the driver
actually still is bound to the device, which is why we need the locking.
