On Sun, Mar 29, 2020 at 03:04:20PM +0200, Lukas Wunner wrote: > Sure, you need to hold the driver in place while you're invoking one of > its callbacks. But is it really necessary to hold the device lock while > performing the actual reset? That locking seems awfully coarse-grained. > > Do you see any potential problem in pushing down the pci_dev_lock() and > pci_dev_unlock() calls into pci_dev_save_and_disable() and > pci_dev_restore()? I.e, acquire the lock for the invocation of > ->reset_prepare() and ->reset_done() and release it immediately > afterwards? > > That would seem to fix the deadlock Michael reported. > > Of course that could result in ->reset_prepare() being invoked but > ->reset_done() being not invoked if the driver is no longer bound. > Or in ->reset_done() being called for a different driver if the > device was rebound in the meantime. Would this cause issues? And at least the driver I'm familiar with (nvme) will be broken by that, as it the state machine expects them to pair.
