Message ID | 20190805160121.27443-1-john@metanate.com (mailing list archive) |
---|---|
State | Mainlined |
Commit | 37bea42fec575203c1b49d64322f717c29e82b90 |
Headers | show |
Series | usb: dwc2: gadget: Fix kill_all_requests race | expand |
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 60ac98cd8ad8..92e8de9cb45c 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -3227,14 +3227,15 @@ static void kill_all_requests(struct dwc2_hsotg *hsotg, struct dwc2_hsotg_ep *ep, int result) { - struct dwc2_hsotg_req *req, *treq; unsigned int size; ep->req = NULL; - list_for_each_entry_safe(req, treq, &ep->queue, queue) - dwc2_hsotg_complete_request(hsotg, ep, req, - result); + while (!list_empty(&ep->queue)) { + struct dwc2_hsotg_req *req = get_ep_head(ep); + + dwc2_hsotg_complete_request(hsotg, ep, req, result); + } if (!hsotg->dedicated_fifos) return;
When a gadget is disabled, kill_all_requests() can be called simultaneously from both a user process via dwc2_hsotg_pullup() and from the interrupt handler if the hardware detects disconnection. Since we drop the lock in dwc2_hsotg_complete_request() in order to call the completion handler, this means that the list is modified concurrently and leads to an infinite loop in kill_all_requests(). Replace the foreach loop with a while-not-empty loop in order to remove the danger of this concurrent modification. Note: I observed this with threadirqs, I'm not sure if it can be triggered without threaded interrupts. Signed-off-by: John Keeping <john@metanate.com> --- drivers/usb/dwc2/gadget.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)