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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 May 2021 17:44:55 +0000
From:   Guido Kiener <Guido.Kiener@...de-schwarz.com>
To:     Alan Stern <stern@...land.harvard.edu>
CC:     Dmitry Vyukov <dvyukov@...gle.com>,
        syzbot <syzbot+e2eae5639e7203360018@...kaller.appspotmail.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "dpenkler@...il.com" <dpenkler@...il.com>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        USB list <linux-usb@...r.kernel.org>,
        "bp@...en8.de" <bp@...en8.de>,
        "dwmw@...zon.co.uk" <dwmw@...zon.co.uk>,
        "hpa@...or.com" <hpa@...or.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "x86@...nel.org" <x86@...nel.org>
Subject: RE: Re: Re: Re: [syzbot] INFO: rcu detected stall in tx

> -----Original Message-----
> From: Alan Stern
> Sent: Thursday, May 6, 2021 3:49 PM
> To: Kiener Guido 14DS1 <Guido.Kiener@...de-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