RE: Re: Re: Re: [syzbot] INFO: rcu detected stall in tx

RE: Re: Re: Re: [syzbot] INFO: rcu detected stall in tx

[Guido Kiener]

> -----Original Message-----
> From: Alan Stern
> Sent: Thursday, May 6, 2021 3:49 PM
> To: Kiener Guido 14DS1 <Guido.Kiener@rohde-schwarz.com>
> 
> On Wed, May 05, 2021 at 10:22:24PM +0000, Guido Kiener wrote:
> > > 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.
> >
> > Thanks for your assessment. I agree with the general feeling. I
> > counted about hundred specific usb drivers, so wouldn't it be better to fix the
> problem in some of the host drivers (e.g. urb.c)?
> > We could return an error when calling usb_submit_urb() on an erroneous pipe.
> > I cannot estimate the side effects and we need to check all drivers
> > again how they deal with the error situation. Maybe there are some special driver
> that need a specialized error handling.
> > In this case these drivers could reset the (new?) error flag to allow
> > calling usb_submit_urb() again without error. This could work, isn't it?
> 
> That is feasible, although it would be an awkward approach.  As you said, the side
> effects aren't clear.  But it might work.

Otherwise I see only the other approach to change hundred drivers and add the
cases EPROTO, EILSEQ and ETIME in each callback handler. The usbtmc driver
already respects the EILSEQ and ETIME, and only EPROTO is missing.
The rest should be more a management task.
BTW do you assume it is only a problem for INT pipes or is it also a problem
for isochronous and bulk transfers?

> > > If you would like to audit drivers and fix them up to behave this
> > > way, that would be great.
> >
> > Currently not. I cannot pull the USB cable in home office :-), but I will keep an eye
> on it.
> > When I'm more involved in the next USB driver issue than I will test
> > bad cables and maybe get more ideas how we could test and fix this rare error.
> 
> Will you be able to test patches?

I only can test the USBTMC function in some different PCs. I do not have automated
regression tests for USB drivers or Linux kernels.
Maybe there is company who could do that.

-Guido

Re: Re: Re: Re: [syzbot] INFO: rcu detected stall in tx

[Alan Stern]

On Thu, May 06, 2021 at 05:44:55PM +0000, Guido Kiener wrote:
> > -----Original Message-----
> > From: Alan Stern
> > Sent: Thursday, May 6, 2021 3:49 PM
> > To: Kiener Guido 14DS1 <Guido.Kiener@rohde-schwarz.com>
> > >
> > > Thanks for your assessment. I agree with the general feeling. I
> > > counted about hundred specific usb drivers, so wouldn't it be better to fix the
> > problem in some of the host drivers (e.g. urb.c)?
> > > We could return an error when calling usb_submit_urb() on an erroneous pipe.
> > > I cannot estimate the side effects and we need to check all drivers
> > > again how they deal with the error situation. Maybe there are some special driver
> > that need a specialized error handling.
> > > In this case these drivers could reset the (new?) error flag to allow
> > > calling usb_submit_urb() again without error. This could work, isn't it?
> > 
> > That is feasible, although it would be an awkward approach.  As you said, the side
> > effects aren't clear.  But it might work.
> 
> Otherwise I see only the other approach to change hundred drivers and add the
> cases EPROTO, EILSEQ and ETIME in each callback handler. The usbtmc driver
> already respects the EILSEQ and ETIME, and only EPROTO is missing.
> The rest should be more a management task.
> BTW do you assume it is only a problem for INT pipes or is it also a problem
> for isochronous and bulk transfers?

All of them.  Control too.

> > Will you be able to test patches?
> 
> I only can test the USBTMC function in some different PCs. I do not have automated
> regression tests for USB drivers or Linux kernels.
> Maybe there is company who could do that.

Well then, if I do find time to write a patch, I'll ask you to try it 
out with the usbtmc driver.

Alan Stern