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

From: Andrey Konovalov <andreyknvl@google.com>
To: Alan Stern <stern@rowland.harvard.edu>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Oliver Neukum <oneukum@suse.com>,
	Colin Ian King <colin.king@canonical.com>,
	Arnd Bergmann <arnd@arndb.de>,
	USB list <linux-usb@vger.kernel.org>,
	syzbot <syzbot+854768b99f19e89d7f81@syzkaller.appspotmail.com>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: [PATCH] USB: cdc-wdm: Call wake_up_all() when clearing WDM_IN_USE bit.
Date: Fri, 29 May 2020 22:41:18 +0200	[thread overview]
Message-ID: <CAAeHK+xx-uodQWBDA2pJ_Et26uBPb6J7fTwu4h6D1uUTv8t3HA@mail.gmail.com> (raw)
In-Reply-To: <20200528205807.GB21709@rowland.harvard.edu>

On Thu, May 28, 2020 at 10:58 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Thu, May 28, 2020 at 09:51:35PM +0200, Andrey Konovalov wrote:
> > 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.
>
> This sounds like a bug in the driver.  What would it do if someone had a
> genuine (not emulated) but buggy USB device which didn't send the
> desired response?  The only way to unblock the driver would be to unplug
> the device!  That isn't acceptable behavior.

OK, that's what I thought.

>
> > 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.
>
> What would happen if you unload dummy-hcd at this point?  Or even just
> do: echo 0 >/sys/bus/usb/devices/usbN/bConfigurationValue, where N is
> the bus number of the dummy-hcd bus?

The device disconnects and flush() unblocks.

> > 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.
>
> Drivers should never go into uninterruptible sleep states unless they
> can guarantee that the duration will be bounded somehow (for example, by
> a reasonable timeout).  Or that cutting the sleep state short would
> cause the system to crash -- but that's not an issue here.

OK, thank you, Alan!

Tetsuo, could you clarify why you think that using
wait_event_interruptible() is a bad fix here?