linux-kernel - Re: [PATCH] rt2x00: Endless loop on hub port power down

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:	Fri, 04 Apr 2014 11:58:26 +0200
From:	Richard Genoud <richard.genoud@...il.com>
To:	Stanislaw Gruszka <sgruszka@...hat.com>
CC:	Ivo van Doorn <IvDoorn@...il.com>,
	Gertjan van Wingerde <gwingerde@...il.com>,
	Helmut Schaa <helmut.schaa@...glemail.com>,
	"John W. Linville" <linville@...driver.com>,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rt2x00: Endless loop on hub port power down

On 04/04/2014 10:04, Stanislaw Gruszka wrote:
> On Thu, Apr 03, 2014 at 04:48:56PM +0200, Richard Genoud wrote:
>> I've met an endless (or at least very long) loop if I power down the usb
>> port on witch a usb wifi key is plugged.
>> (Ok, it's not very smart to power down a usb port when a usb key is in
>> used... but still, I think that should not lead to an endless loop).
>>
>> I have a lot of:
>> ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71
>>
>> (-71==-EPROTO)
>>
>> How to reproduce:
>> - plug an usb wifi key
>> - ip link set wlan0 up
>> - hub-ctrl -b usb_bus -d usb_device -P usb_port -p 0
>>
>> hub-ctrl source: https://github.com/codazoda/hub-ctrl.c/blob/master/hub-ctrl.c
>>
>> The following patch prevents the endless loop, but I'm really not sure
>> that The Right Way To Do It (R)
> 
> If device disappear, we should get -ENODEV status, why we get -EPROTO ?

I trace it down, and the EPROTO status comes from ctx.status (returned from usb_start_wait_urb() in drivers/usb/core/message.c)
And, in my case, the ctx.status is set to EPROTO in qtd_copy_status() ( drivers/usb/host/ehci-q.c )
in the code:
} else if (token & QTD_STS_XACT) {
	/* timeout, bad CRC, wrong PID, etc */
	ehci_dbg(ehci, "devpath %s ep%d%s 3strikes\n",
		urb->dev->devpath,
		usb_pipeendpoint(urb->pipe),
		usb_pipein(urb->pipe) ? "in" : "out");
	status = -EPROTO;

enabling this log, I get:
atmel-ehci 700000.ehci: devpath 2.1 ep1in 3strikes
atmel-ehci 700000.ehci: devpath 2.1 ep0in 3strikes
atmel-ehci 700000.ehci: devpath 2.1 ep1in 3strikes
atmel-ehci 700000.ehci: devpath 2.1 ep0in 3strikes
ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71

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