Re: [PATCH] USB: cdc-wdm: Call wake_up_all() when clearing WDM_IN_USE bit.

[Andrey Konovalov <andreyknvl@google.com>]

On Thu, May 28, 2020 at 9:40 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Thu, May 28, 2020 at 09:03:43PM +0200, Andrey Konovalov wrote:
>
> > Ah, so the problem is that when a process exits, it tries to close wdm
> > fd first, which ends up calling wdm_flush(), which can't finish
> > because the USB requests are not terminated before raw-gadget fd is
> > closed, which is supposed to happen after wdm fd is closed. Is this
> > correct? I wonder what will happen if a real device stays connected
> > and ignores wdm requests.
> >
> > I don't understand though, how using wait_event_interruptible() will
> > shadow anything here.
> >
> > Alan, Greg, is this acceptable behavior for a USB driver?
>
> I don't understand what the problem is.  Can you explain in more general
> terms -- nothing specific to wdm or anything like that -- what you are
> concerned about?  Is this something that could happen to any gadget
> driver?  Or any USB class device driver?  Or does it only affect
> usespace components of raw-gadget drivers?

So, AFAIU, we have a driver whose flush() callback blocks on
wait_event(), which can only terminate when either 1) the driver
receives a particular USB response from the device or 2) the device
disconnects. For 1) the emulated device doesn't provide required
responses. For 2) the problem is that the emulated via raw-gadget
device disconnects when the process is killed (and raw-gadget fd is
closed). But that process is the same process that is currently stuck
on wait_event() in the flush callback(), and therefore unkillable.

This can generally happen with any driver that goes into
uninterruptible sleep within one of its code paths reachable from
userspace that can only be unblocked by a particular behavior from the
USB device. But I haven't seen any such drivers so far, wdm is the
first.