Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1735108
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: usb/gadget: stalls in dummy_timer |
| Date | 2017-09-19 19:20 +0200 |
| Message-ID | <urulI-8fP-3@gated-at.bofh.it> (permalink) |
| References | <urqBs-5WC-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, 19 Sep 2017, Andrey Konovalov wrote:
> 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.
Got it, thanks. Can you test the patch below in place of (or in
addition to) the earlier patch?
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
@@ -237,6 +237,8 @@ struct dummy_hcd {
struct usb_device *udev;
struct list_head urbp_list;
+ struct urbp *next_frame_urbp;
+
u32 stream_en_ep;
u8 num_stream[30 / 2];
@@ -1252,6 +1254,8 @@ static int dummy_urb_enqueue(
list_add_tail(&urbp->urbp_list, &dum_hcd->urbp_list);
urb->hcpriv = urbp;
+ if (!dum_hcd->next_frame_urbp)
+ dum_hcd->next_frame_urbp = urbp;
if (usb_pipetype(urb->pipe) == PIPE_CONTROL)
urb->error_count = 1; /* mark as a new urb */
@@ -1768,6 +1772,7 @@ static void dummy_timer(unsigned long _d
spin_unlock_irqrestore(&dum->lock, flags);
return;
}
+ dum_hcd->next_frame_urbp = NULL;
for (i = 0; i < DUMMY_ENDPOINTS; i++) {
if (!ep_info[i].name)
@@ -1784,6 +1789,10 @@ restart:
int type;
int status = -EINPROGRESS;
+ /* stop when we reach URBs queued after the timer interrupt */
+ if (urbp == dum_hcd->next_frame_urbp)
+ break;
+
urb = urbp->urb;
if (urb->unlinked)
goto return_urb;
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
usb/gadget: stalls in dummy_timer Andrey Konovalov <andreyknvl@google.com> - 2017-09-11 13:20 +0200
Re: usb/gadget: stalls in dummy_timer Alan Stern <stern@rowland.harvard.edu> - 2017-09-11 15:40 +0200
Re: usb/gadget: stalls in dummy_timer Andrey Konovalov <andreyknvl@google.com> - 2017-09-11 17:20 +0200
Re: usb/gadget: stalls in dummy_timer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-11 21:00 +0200
Re: usb/gadget: stalls in dummy_timer Andrey Konovalov <andreyknvl@google.com> - 2017-09-12 17:50 +0200
Re: usb/gadget: stalls in dummy_timer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-12 19:10 +0200
Re: usb/gadget: stalls in dummy_timer Andrey Konovalov <andreyknvl@google.com> - 2017-09-14 18:10 +0200
Re: usb/gadget: stalls in dummy_timer Alan Stern <stern@rowland.harvard.edu> - 2017-09-14 19:50 +0200
Re: usb/gadget: stalls in dummy_timer Andrey Konovalov <andreyknvl@google.com> - 2017-09-14 20:00 +0200
Re: usb/gadget: stalls in dummy_timer Alan Stern <stern@rowland.harvard.edu> - 2017-09-15 21:00 +0200
Re: usb/gadget: stalls in dummy_timer Andrey Konovalov <andreyknvl@google.com> - 2017-09-19 15:20 +0200
Re: usb/gadget: stalls in dummy_timer Alan Stern <stern@rowland.harvard.edu> - 2017-09-19 19:20 +0200
Re: usb/gadget: stalls in dummy_timer Andrey Konovalov <andreyknvl@google.com> - 2017-09-19 19:30 +0200
csiph-web