[PATCH 06/18] staging: gasket: fix deadlock in pci driver unregister path

[Todd Poynor]

On Sat, Jul 14, 2018 at 5:57 AM, Greg Kroah-Hartman
<gregkh at 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 <toddpoynor at gmail.com> wrote:
>> >
>> > From: Todd Poynor <toddpoynor at google.com>
>> >
>> > g_mutex held across pci_unregister_driver() call, also held in
>> > gasket_pci_remove(), which deadlocks.
>> >
>> > Reported-by: Dmitry Torokhov <dtor at chromium.org>
>> > Signed-off-by: Zhongze Hu <frankhu at chromium.org>
>> > Signed-off-by: Todd Poynor <toddpoynor at 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