Hi Felipe,
On Fri, Mar 23, 2018 at 10:05:33AM -0700, Jack Pham wrote:
> dwc3_ep_dequeue() waits for completion of End Transfer command
> using wait_event_lock_irq(), which will release the dwc3->lock
> while waiting and reacquire after completion. This allows a
> potential race condition with ep_disable() which also removes
> all requests from started_list and pending_list. The check for
> NULL r->trb should catch this but currently it exits to the
> wrong 'out1' label which calls dwc3_gadget_giveback(). Since
> its list entry was already removed, if CONFIG_DEBUG_LIST is
> enabled a 'list_del corruption' bug is thrown since its
> next/prev pointers are already LIST_POISON1/2. If r->trb is
> NULL it should simply exit to 'out0'.
>
> Fixes: cf3113d893d4 ("usb: dwc3: gadget: properly increment dequeue pointer
> on ep_dequeue")
Upon taking a second look at this patch, and noting the subject of the
Fixes tag here, one side effect of this fix is that dep->queued_requests
won't get decremented. I see this is a counter for tracing purposes so
probably doesn't affect function. But it begs the question of whether
dwc3_remove_requests() as called from __dwc3_gadget_ep_disable() should
have decremented this counter or even zeroed it out completely?
> if (!r->trb)
> - goto out1;
> + goto out0;
>
Thanks,
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
