| Message ID | Pine.LNX.4.44L0.1709141242040.9284-100000@netrider.rowland.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Thu, 14 Sep 2017, Andrey Konovalov wrote: > >> 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! > > Alan Stern > > > > Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c > =================================================================== > --- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c > +++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c > @@ -1781,7 +1781,6 @@ restart: > struct dummy_request *req; > u8 address; > struct dummy_ep *ep = NULL; > - int type; > int status = -EINPROGRESS; > > urb = urbp->urb; > @@ -1789,14 +1788,10 @@ restart: > goto return_urb; > else if (dum_hcd->rh_state != DUMMY_RH_RUNNING) > continue; > - type = usb_pipetype(urb->pipe); > > - /* used up this frame's non-periodic bandwidth? > - * FIXME there's infinite bandwidth for control and > - * periodic transfers ... unrealistic. > - */ > - if (total <= 0 && type == PIPE_BULK) > - continue; > + /* Used up this frame's bandwidth? */ > + if (total <= 0) > + break; > > /* find the gadget's ep for this request (if configured) */ > address = usb_pipeendpoint (urb->pipe); > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 15, 2017 at 8:57 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Thu, 14 Sep 2017, Andrey Konovalov wrote: > >> On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern <stern@rowland.harvard.edu> wrote: >> > On Thu, 14 Sep 2017, Andrey Konovalov wrote: >> > >> >> 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 >
Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c =================================================================== --- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c +++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c @@ -1781,7 +1781,6 @@ restart: struct dummy_request *req; u8 address; struct dummy_ep *ep = NULL; - int type; int status = -EINPROGRESS; urb = urbp->urb; @@ -1789,14 +1788,10 @@ restart: goto return_urb; else if (dum_hcd->rh_state != DUMMY_RH_RUNNING) continue; - type = usb_pipetype(urb->pipe); - /* used up this frame's non-periodic bandwidth? - * FIXME there's infinite bandwidth for control and - * periodic transfers ... unrealistic. - */ - if (total <= 0 && type == PIPE_BULK) - continue; + /* Used up this frame's bandwidth? */ + if (total <= 0) + break; /* find the gadget's ep for this request (if configured) */ address = usb_pipeendpoint (urb->pipe);