Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751681AbdIOS56 (ORCPT ); Fri, 15 Sep 2017 14:57:58 -0400 Received: from netrider.rowland.org ([192.131.102.5]:60709 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751517AbdIOS55 (ORCPT ); Fri, 15 Sep 2017 14:57:57 -0400 Date: Fri, 15 Sep 2017 14:57:55 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Andrey Konovalov cc: Dmitry Torokhov , Henrik Rydberg , "linux-input@vger.kernel.org" , Felipe Balbi , Greg Kroah-Hartman , Johan Hovold , Peter Chen , Yuyang Du , USB list , LKML , Dmitry Vyukov , Kostya Serebryany , syzkaller Subject: Re: usb/gadget: stalls in dummy_timer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1519 Lines: 38 On Thu, 14 Sep 2017, Andrey Konovalov wrote: > On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern 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. Alan Stern