On Thu, May 28, 2020 at 9:40 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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.
