aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci/controller/pci-host-common.c
diff options
context:
space:
mode:
authorUttkarsh Aggarwal <[email protected]>2023-05-25 09:28:54 +0000
committerGreg Kroah-Hartman <[email protected]>2023-05-29 14:24:08 +0000
commitefb6b535207395a5c7317993602e2503ca8cb4b3 (patch)
tree6aa65b49298a21b88691dd19a5d656c87b27562b /drivers/pci/controller/pci-host-common.c
parentusb: cdns3: fix NCM gadget RX speed 20x slow than expection at iMX8QM (diff)
downloadkernel-efb6b535207395a5c7317993602e2503ca8cb4b3.tar.gz
kernel-efb6b535207395a5c7317993602e2503ca8cb4b3.zip
usb: gadget: f_fs: Add unbind event before functionfs_unbind
While exercising the unbind path, with the current implementation the functionfs_unbind would be calling which waits for the ffs->mutex to be available, however within the same time ffs_ep0_read is invoked & if no setup packets are pending, it will invoke function wait_event_interruptible_exclusive_locked_irq which by definition waits for the ev.count to be increased inside the same mutex for which functionfs_unbind is waiting. This creates deadlock situation because the functionfs_unbind won't get the lock until ev.count is increased which can only happen if the caller ffs_func_unbind can proceed further. Following is the illustration: CPU1 CPU2 ffs_func_unbind() ffs_ep0_read() mutex_lock(ffs->mutex) wait_event(ffs->ev.count) functionfs_unbind() mutex_lock(ffs->mutex) mutex_unlock(ffs->mutex) ffs_event_add() <deadlock> Fix this by moving the event unbind before functionfs_unbind to ensure the ev.count is incrased properly. Fixes: 6a19da111057 ("usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait") Cc: stable <[email protected]> Signed-off-by: Uttkarsh Aggarwal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Diffstat (limited to 'drivers/pci/controller/pci-host-common.c')
0 files changed, 0 insertions, 0 deletions