On Sat, Jul 14, 2018 at 5:57 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, Jul 14, 2018 at 11:07:21AM +0300, Dmitry Torokhov wrote: >> On Sat, Jul 14, 2018 at 8:58 AM Todd Poynor <toddpoynor@xxxxxxxxx> wrote: >> > >> > From: Todd Poynor <toddpoynor@xxxxxxxxxx> >> > >> > g_mutex held across pci_unregister_driver() call, also held in >> > gasket_pci_remove(), which deadlocks. >> > >> > Reported-by: Dmitry Torokhov <dtor@xxxxxxxxxxxx> >> > Signed-off-by: Zhongze Hu <frankhu@xxxxxxxxxxxx> >> > Signed-off-by: Todd Poynor <toddpoynor@xxxxxxxxxx> >> > --- >> > drivers/staging/gasket/gasket_core.c | 7 ++----- >> > 1 file changed, 2 insertions(+), 5 deletions(-) >> > >> > diff --git a/drivers/staging/gasket/gasket_core.c b/drivers/staging/gasket/gasket_core.c >> > index 3bdf7d36b397..6d240dc59557 100644 >> > --- a/drivers/staging/gasket/gasket_core.c >> > +++ b/drivers/staging/gasket/gasket_core.c >> > @@ -668,13 +668,10 @@ static void gasket_pci_remove(struct pci_dev *pci_dev) >> > struct gasket_dev *gasket_dev = NULL; >> > const struct gasket_driver_desc *driver_desc; >> > /* Find the device desc. */ >> > - mutex_lock(&g_mutex); >> > + __must_hold(&g_mutex); >> >> And what exactly ensures that mutex is held here? Yes, we are holding >> the mutex when we unload the driver, but PCI hot-unplug or unbinding >> the device though sysfs do not go through module unload code path, so >> you'll end up here without holding the mutex. > > Which is a huge reason the whole "wrap the pci core calls" is not going > to work here at all. The device ownership rules are all wonky because > of this. Unwinding that is key to getting all of this right. OK, I'll drop this patch in favor of redoing things not to wrap PCI core calls in the future, thanks. > > thanks, > > greg k-h -- Todd _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
