* possible deadlock in 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c ("usb hub: send clear_tt_buffer_complete events when canceling TT clear work")
@ 2019-06-18 14:12 Oliver Neukum
0 siblings, 0 replies; only message in thread
From: Oliver Neukum @ 2019-06-18 14:12 UTC (permalink / raw)
To: Octavian Purdila, Alan Stern; +Cc: linux-usb
Hi,
looking at this code, which fixed a deadlock,it looks to me
like it has introduced another deadlock.
[assume a storage device on a hub being suspended]
hub_suspend() -> hub_quiesce() -> flush_work(&hub->tt.clear_work) ->
/* note that tt.clear_work is not on its own queue, it uses
simple schedule_work(). Hence the work lands on system_wq,
shared with arbitrary works */
kmalloc(... , GFP_KERNEL) -> usb_storage or uas ->
usb_autopm_get_interface() -> DEADLOCK
I think you need to use a dedicated workqueue for the hub driver.
Regards
Oliver
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-06-18 14:26 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-18 14:12 possible deadlock in 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c ("usb hub: send clear_tt_buffer_complete events when canceling TT clear work") Oliver Neukum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.