Re: [PATCH] usb: dwc3: gadget: don't dequeue requests on already disabled endpoints - Lars-Peter Clausen

From: Lars-Peter Clausen <lars@metafoo.de>
To: Michael Grzeschik <mgr@pengutronix.de>
Cc: alexandru.Ardelean@analog.com, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, balbi@kernel.org,
	gregkh@linuxfoundation.org, bigeasy@linutronix.de,
	m.olbrich@pengutronix.de, kernel@pengutronix.de
Subject: Re: [PATCH] usb: dwc3: gadget: don't dequeue requests on already disabled endpoints
Date: Fri, 27 Mar 2020 11:55:41 +0100	[thread overview]
Message-ID: <c2bbd132-c482-21c4-232d-2786021759cf@metafoo.de> (raw)
In-Reply-To: <20200327104352.GF27849@pengutronix.de>

On 3/27/20 11:43 AM, Michael Grzeschik wrote:
> On Fri, Mar 27, 2020 at 10:14:10AM +0100, Lars-Peter Clausen wrote:
>> On 3/27/20 9:43 AM, Michael Grzeschik wrote:
>>> dwc3_gadget_ep_disable gets called before the last request gets
>>> dequeued.
>>>
>>> In __dwc3_gadget_ep_disable all started, pending and cancelled
>>> lists for this endpoint will call dwc3_gadget_giveback in
>>> dwc3_remove_requests.
>>>
>>> After that no list containing the afterwards dequed request,
>>> therefor it is not necessary to run the dequeue routine.
>>>
>>> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
>>> ---
>>> @Lars-Peter Clausen:
>>>
>>> This patch addresses the case that not queued requests get dequeued.
>>> The only case that this happens seems on disabling the gadget.
>>
>> I don't believe it does. Calling usb_ep_dequeue() is not limited to be
>> called after the endpoint has been disabled. It is part of the API and can
>> be called at any time. E.g. with function_fs you can abort a queued transfer
>> from userspace at any time.
> OK, can you give me an Userspace example how to simply trigger the
> issue. I tried to figure your mentioned function stack but it would
> be much easier if it could be reproduced.
>
> The patch on the other hand can stand on itself, as it then
> fixes another code path that is much more common.

Hi,

I don't have a standalone example. But the issue occurs if you submit a 
request when using function_fs through the AIO API and then call 
io_cancel() to abort it. At the same time there must be traffic on the 
USB bus so that the URB has a chance to complete.

This is a race condition between the IRQ handler running on one CPU and 
the usb_ep_dequeue() running on another CPU. As such it might take a 
while of stress testing before it is triggered. The more CPUs your 
system has the higher the chance of trigger the issue.

You can find the code which triggers the issue below.

Submission of the request:

https://github.com/analogdevicesinc/libiio/blob/master/iiod/ops.c#L139-L156

Canceling it:

https://github.com/analogdevicesinc/libiio/blob/master/iiod/ops.c#L193