> > > 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. > > Ah yes, now I remember. > > That message doesn't show the _device_ recovering and continuing to operate, > though. It shows the _system_ recovering and realizing that the device has been > disconnected. > > What I was asking about was whether you knew of a case where there was an > EPROTO error but afterward the usbtmc device continued to work -- no > disconnection. Assuming such cases are vanishingly rare, there's no harm in > having the driver give up whenever it encounters EPROTO. I have no idea how often the EPROTO error can happen during normal operation and believe you that it's vanishingly rare. When it happens, does the USB hardware protocol automatically retransmit the lost/invalid packet? If yes, we should think about an error counter. If not, then we really can stop the INT pipe and the user will detect that something is wrong when reading the status. > > 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. > > Both drivers contributed to the lockup. The question is: Which driver was doing the > wrong thing? (Or which was _more_ wrong?) I believe the usbtmc driver was. > > > 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. > > Agreed. So Greg should go ahead and apply the $SUBJECT patch. > > Alan Stern
