lkml.org 
[lkml]   [2021]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Re: [syzbot] INFO: rcu detected stall in tx
On Mon, May 03, 2021 at 09:56:05PM +0000, Guido Kiener wrote:
> Hi all,
>
> Dave and I discussed the "self-detected stall on CPU" caused by the usbtmc driver.
>
> What happened?
> The callback handler usbtmc_interrupt(struct urb *urb) for the INT pipe receives an erroneous urb with status -EPROTO (-71).
> See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/class/usbtmc.c?h=v5.12#n2340
> -EPROTO does not abort/shutdown the pipe and the urb is resubmitted to receive the next packet. However the callback handler usbtmc_interrupt is called again with the same erroneous status -EPROTO and this seems to result in an endless loop.
> According to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/usb/error-codes.rst?h=v5.12#n177
> the error -EPROTO indicates a hardware problem or a bad cable.
>
> Most usb drivers do not react in a specific way on this hardware problems and resubmit the urb. We assume these drivers will run into the same endless loop. Some other driver samples are:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/class/cdc-acm.c?h=v5.12#n379
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/usbhid/usbmouse.c?h=v5.12#n65
>
> Possible solutions:
> Hardware defects or bad cables seems to be a common problem for most usb drivers and I assume we do not want to fix this problem in all class specific drivers, but in lower level host drivers, e.g:
> 1. Using a counter and close the pipe after some detected errors
> 2. Delay the resubmission of the urb to avoid high cpu usage
> 3. Do nothing, since it is just a rare problem.
>
> We've never seen this problem in our products and we do not dare to change anything.

Drivers are not consistent in the way they handle these errors, as you
have seen. A few try to take active measures, such as retrys with
increasing timeouts. Many drivers just ignore them, which is not a very
good idea.

The general feeling among kernel USB developers is that a -EPROTO,
-EILSEQ, or -ETIME error should be regarded as fatal, much the same as
an unplug event. The driver should avoid resubmitting URBs and just
wait to be unbound from the device.

If you would like to audit drivers and fix them up to behave this way,
that would be great.

(FYI, by far the most common causes of these errors are: The user has
unplugged the USB cable, or the device's firmware has crashed. It is
quite rare for the cause to be intermittent, although not entirely
unheard of -- for example, someone once reported errors resulting from
EM or power-line interference caused by flickering fluorescent lights or
something of that sort. It's pretty safe to ignore this possibility.)

Alan Stern

\
 
 \ /
  Last update: 2021-05-04 17:15    [W:0.381 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site