Re: usb/gadget: stalls in dummy_timer

On Fri, Sep 15, 2017 at 8:57 PM, Alan Stern [off-list ref] wrote:

On Thu, 14 Sep 2017, Andrey Konovalov wrote:

quoted

On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern [off-list ref] wrote:

quoted

On Thu, 14 Sep 2017, Andrey Konovalov wrote:

quoted

Looked at this a little more.

dummy_timer() stucks in an infinite loop. It calls
usb_hcd_giveback_urb(), which in turn calls usbtouch_irq(), which
calls usb_submit_urb(), which calls dummy_urb_enqueue() and puts urb
back into dummy urb queue. dummy_timer() then does goto restart, finds
the urb and calls usb_hcd_giveback_urb() again. And this process goes
on again and again. It seems that something should either process the
urb and set urb->status or it should just expire.

There is some throttling code, but it applies only to bulk transfers.
Probably because the bandwidth limits for other types are slightly
different.  However, I don't think we need to worry about this level of
detail, since the driver makes a number of other approximations anyway.

Try the patch below; it should fix the problem.

Hi Alan,

Just tried your patch, my reproducer still hangs the kernel until all
memory is exhausted.

Thanks!

Hmmm.  Your reproducer doesn't run on my system.  The mmap system call
fails, perhaps because this laptop has a 32-bit kernel.  So I can't
tell what's going on.

Can you collect a usbmon trace that shows what happens while the
reproducer runs?  If it turns out to be extremely large, just post an
initial portion of it.

I've attached the usbmon trace. It's actually quite short, probably
due to the fact that the kernel enters infinite loop.

I've also attached a reproducer that should compile on a 32 bit
system, however I haven't tested whether it reproduces the issue.

Alan Stern