> -----Original Message----- > From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, July 21, 2021 4:22 PM > To: dave penkler <dpenkler@xxxxxxxxx> > Cc: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>; qiang.zhang@xxxxxxxxxxxxx; Dmitry > Vyukov <dvyukov@xxxxxxxxxx>; paulmck@xxxxxxxxxx; Kiener Guido 14DS1 > <Guido.Kiener@xxxxxxxxxxxxxxxxx>; USB <linux-usb@xxxxxxxxxxxxxxx> > Subject: *EXT* Re: [PATCH] USB: usbtmc: Fix RCU stall warning > > On Wed, Jul 21, 2021 at 11:44:23AM +0200, dave penkler wrote: > > Sorry, the issue this patch is trying to fix occurs because the > > current usbtmc driver resubmits the URB when it gets an EPROTO return. > > The dummy usb host controller driver used in the syzbot tests keeps > > returning the resubmitted URB with EPROTO causing a loop that starves > > RCU. With an actual HCI driver it either recovers or returns an EPIPE. > > Are you sure about that? Have you ever observed a usbtmc device recovering and > continuing to operate after an EPROTO error? I can't speak for Dave and his investigations. However as you remember I did tests with EPROTO errors, see thread: https://marc.info/?l=linux-usb&m=162163776930423&w=2 In the thread you can see the recovering. Since no user blamed the usbtmc driver for system locks up to now, it's worth to think about whether the problem is caused by the dummy_hcd driver. I still have no time for further investigations and would agree to use the simple patch to get rid of the topic for the usbtmc driver. Then the syzbot will maybe find another usb driver. -Guido > An EPIPE error also seems rather unlikely -- particularly if the device is not plugged > into a high-speed hub. > > Alan Stern > > > In either case no loop occurs. So for my part as a user and maintainer > > this patch is not ok.
