linux-kernel - Re: [PATCH] usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Nov 2013 10:32:33 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Julius Werner <jwerner@...omium.org>
cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Benson Leung <bleung@...omium.org>,
	Vincent Palatin <vpalatin@...omium.org>
Subject: Re: [PATCH] usb: hub: Use correct reset for wedged USB3 devices that
 are NOTATTACHED

On Wed, 6 Nov 2013, Julius Werner wrote:

> > What if the device is in USB_STATE_SUSPENDED?
> 
> I'm not sure that is possible at that point in hub_events(), I don't
> know of a way that could lead to this situation. I could still add the
> check just to be sure if you want it, though.

I don't know either.  But Sarah has said that ports can spontaneously
go into Compliance Mode for no apparent reason.  If that can happen,
maybe it can happen while the port is in U3 and the device is
suspended.  In such cases, though, you'd need to do a reset-resume
rather than a simple reset.

> > Not at all.  If a device is unplugged, its state changes to NOTATTACHED
> > before the driver is unbound.  During that time, the driver will see
> > all its URBs failing, so it may very well try to reset the device.
> > (For example, usbhid behaves like this.)  That isn't a bug.
> 
> Oh, okay, I wasn't quite sure how that plays together. Would you think
> it's still valuable to print it out (maybe as dev_info() instead of
> dev_warn()) instead of just silently ignoring the reset request? It
> would have certainly been useful for me to find this problem faster,
> but I can take it out again if you think it would result in too much
> noise.

I think keeping dev_dbg() is best.  If you're searching for the
solution to a problem, you should have debugging enabled and so you
ought to see the message.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/