usb: gadget: pch_udc: reorder spin_[un]lock to avoid deadlock
authorIago Abal <mail@iagoabal.eu>
Tue, 21 Jun 2016 10:01:11 +0000 (12:01 +0200)
committerFelipe Balbi <felipe.balbi@linux.intel.com>
Tue, 21 Jun 2016 10:18:23 +0000 (13:18 +0300)
commit1d23d16a88e6c8143b07339435ba061b131ebb8c
treeb75774f24a265c62d78ca54b1778115b1d4e0419
parent43202800010102a857ffb119429d7dc5b41b7096
usb: gadget: pch_udc: reorder spin_[un]lock to avoid deadlock

The above commit reordered spin_lock/unlock and now `&dev->lock' is acquired
(rather than released) before calling `dev->driver->disconnect',
`dev->driver->setup', `dev->driver->suspend', `usb_gadget_giveback_request', and
`usb_gadget_udc_reset'.

But this *may* not be the right way to fix the problem pointed by d3cb25a12138.

Note that the other usb/gadget/udc drivers do release the lock before calling
these functions. There are also inconsistencies within pch_udc.c, where
`dev->driver->disconnect' is called while holding `&dev->lock' in lines 613 and
1184, but not in line 2739.

Finally, commit d3cb25a12138 may have introduced several potential deadlocks.

For instance, EBA (https://github.com/models-team/eba) reports:

    Double lock in drivers/usb/gadget/udc/pch_udc.c
    first at 2791: spin_lock(& dev->lock); [pch_udc_isr]
    second at 2694: spin_lock(& dev->lock); [pch_udc_svc_cfg_interrupt]
        after calling from 2793: pch_udc_dev_isr(dev, dev_intr);
        after calling from 2724: pch_udc_svc_cfg_interrupt(dev);

Similarly, other potential deadlocks are 2791 -> 2793 -> 2721 -> 2657; and
2791 -> 2793 -> 2711 -> 2573 -> 1499 -> 1480.

Fixes: d3cb25a12138 ("usb: gadget: udc: fix spin_lock in pch_udc")
Signed-off-by: Iago Abal <mail@iagoabal.eu>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
drivers/usb/gadget/udc/pch_udc.c