usb: gadget: ffs: Fix BUG when userland exits with submitted AIO transfers

[Felipe Balbi <felipe.balbi@linux.intel.com>]

Hi,

Alan Stern <stern@rowland.harvard.edu> writes:
> On Thu, 21 Jun 2018, Roger Quadros wrote:
>
>> >> Can we avoid the spin_lock() and the work-queue and call usb_ep_dequeue() directly from here?
>> >>> What is the purpose of the spin_lock()?
>> > 
>> > I agree that the lock doesn't seem to be necessary. But I believe the whole
>> > thing is already running in non-sleeping context, even before the spinlock
>> > is taken. So this wouldn't help much.
>> > 
>> > Even the io_cancel() syscall takes a spinlock before invoking the cancel
>> > function. So this issue is not exclusive to program termination.
>> > 
>> > Are there any documented guidelines on which context usb_ep_dequeue() should
>> > be able to be called in? The sleep in the dwc3 driver seems to be a recent
>> > addition.
>> 
>> drivers/usb/udc/gadget/core.c has the only documentation, but context is not mentioned there.
>> Felipe, what do you suggest?
>
> As far as I remember, usb_ep_dequeue() is supposed to be more or less 
> analogous to usb_ep_queue(); drivers should be allowed to call either 
> routine in an atomic context.

Hmm, that's what I remember, but we don't have that documented and dwc3
has a sleep in its dequeue, which I need to remove for other reasons
anyway.

Can we get a patch updating documentation to make it clear that both
queue and dequeue should be callable from any context?