From: Alan Stern <stern@rowland.harvard.edu> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andrey Konovalov <andreyknvl@google.com>, syzbot <syzbot+b24d736f18a1541ad550@syzkaller.appspotmail.com>, Felipe Balbi <balbi@kernel.org>, <chunfeng.yun@mediatek.com>, LKML <linux-kernel@vger.kernel.org>, USB list <linux-usb@vger.kernel.org>, syzkaller-bugs <syzkaller-bugs@googlegroups.com>, Dmitry Vyukov <dvyukov@google.com> Subject: Re: INFO: rcu detected stall in dummy_timer Date: Mon, 16 Sep 2019 15:48:23 -0400 (EDT) Message-ID: <Pine.LNX.4.44L0.1909161525340.1489-100000@iolanthe.rowland.org> (raw) In-Reply-To: <20190916185933.GA1814003@kroah.com> On Mon, 16 Sep 2019, Greg Kroah-Hartman wrote: > On Mon, Sep 16, 2019 at 12:32:52PM -0400, Alan Stern wrote: > > Retry-limiting is not the sort of thing we want to add to each > > individual USB class driver. Maybe it can be handled in the USB core; > > I'll try to write some code for it. Under normal circumstances the > > issue just doesn't arise, because normal devices aren't malicious. > > I think this issue came up years ago when people realized they could > "abuse" this through usbfs, but maybe I am mistaken. > > The "do we retry or not" is an old discussion, and one I think we just > said, "if it errors out, we will not retry as something is wrong with > the device". Really? I bet there are plenty of drivers whose interrupt-URB (or whatever) completion handlers just log an error message and blindly resubmit when they get an unexpected kind of error. > Corrupted packets don't seem to be something that is even > noticable in the "real world". When lots of noise happens on a system > that might cause this, usually the hub just disconnects the device and > resets it. I recall hearing from someone (many years ago -- the technology has certainly improved since then) about a device that would start getting errors whenever a noisy fluorescent light near the computer was switched on. :-) But yes, this sort of thing is very uncommon. So do you recommend editing drivers to prevent them from resubmitting URBs whenever they get an unrecognized error, such as -EPROTO, -EILSEQ, or -ETIME? Then the driver would most likely stop working when one of these errors happens. Alternatively, the USB core could keep track of these three kinds of bus errors for all endpoints and fail submissions when the error count gets too high. That would end up having the same effect -- drivers would stop working -- but it might be a little more robust against noise and it wouldn't require editing lots of drivers. Alan Stern
next prev parent reply index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-09 13:18 syzbot 2019-09-13 19:56 ` syzbot 2019-09-13 20:35 ` Alan Stern 2019-09-16 15:29 ` Andrey Konovalov 2019-09-16 16:32 ` Alan Stern 2019-09-16 18:59 ` Greg Kroah-Hartman 2019-09-16 19:48 ` Alan Stern [this message] 2019-09-18 11:22 ` Andrey Konovalov 2019-09-18 14:16 ` Alan Stern 2019-09-16 19:53 ` Alan Stern 2019-09-16 20:13 ` syzbot 2019-09-17 16:47 ` [PATCH] USB: yurex: Don't retry on unexpected errors Alan Stern
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.4.44L0.1909161525340.1489-100000@iolanthe.rowland.org \ --to=stern@rowland.harvard.edu \ --cc=andreyknvl@google.com \ --cc=balbi@kernel.org \ --cc=chunfeng.yun@mediatek.com \ --cc=dvyukov@google.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=syzbot+b24d736f18a1541ad550@syzkaller.appspotmail.com \ --cc=syzkaller-bugs@googlegroups.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-USB Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-usb/0 linux-usb/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-usb linux-usb/ https://lore.kernel.org/linux-usb \ linux-usb@vger.kernel.org public-inbox-index linux-usb Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb AGPL code for this site: git clone https://public-inbox.org/public-inbox.git