linux-kernel - Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

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

Message-ID: <CAODwPW-edQv19FS2zA7uEK6pnegfrjb+ikyb7EaFWnjBF+3O0Q@mail.gmail.com>
Date:	Wed, 31 Jul 2013 11:49:15 -0700
From:	Julius Werner <jwerner@...omium.org>
To:	Alan Stern <stern@...land.harvard.edu>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
Cc:	Julius Werner <jwerner@...omium.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-usb@...r.kernel.org,
	Vincent Palatin <vpalatin@...omium.org>,
	Benson Leung <bleung@...omium.org>
Subject: Re: [PATCH] usb: core: don't try to reset_device() a port that got
 just disconnected

> An odd sort of bug.  You'd think that not getting a response back would
> be one of the first types of error the hardware designers would check
> for.

You'd think that, right? But apparently they didn't. I've now also
tried just hacking a pointless SET_INTERFACE message into the
hub_port_connect_change() handler on disconnect... stalls every time
with both 2.0 and 3.0 devices (and fails fast as expected on
PantherPoint). I have a feeling that this might not be the last
fix/workaround we will need for this PCH...

> Hmm, 5 seconds is the xHCI command timeout.  Could the driver be
> possibly issuing either a Reset Device or Address Device command that
> simply times out?

The timeout is USB_CTRL_SET_TIMEOUT from
usb_set_device_initiated_lpm() (ends up in usb_start_wait_urb()). I
have dumped all XHCI commands and events in my tests... there were no
commands enqueued or completed in that timeframe, and no transfer
events received for that endpoint. I've also checked the endpoint
context before and 200ms after enqueueing the transfer, and it was
still in the "Running" state. The xHC just seems to completely hang on
that transfer ring until the timeout hits and the kernel issues a Stop
Endpoint to abort the URB.

> Thanks Alan, I'll send this off to Greg shortly.

Thanks!
--
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/