On Sat, Jul 14, 2018 at 5:57 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> 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 <toddpoy...@gmail.com> wrote: >> > >> > From: Todd Poynor <toddpoy...@google.com> >> > >> > g_mutex held across pci_unregister_driver() call, also held in >> > gasket_pci_remove(), which deadlocks. >> > >> > Reported-by: Dmitry Torokhov <d...@chromium.org> >> > Signed-off-by: Zhongze Hu <fran...@chromium.org> >> > Signed-off-by: Todd Poynor <toddpoy...@google.com> >> > --- >> > 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 de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
