linux-kernel - Re: [linux-usb-devel] OHCI root_port

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20071009192250.BD703236A37@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
Date:	Tue, 09 Oct 2007 12:22:50 -0700
From:	David Brownell <david-b@...bell.net>
To:	stern@...land.harvard.edu, linux-usb-devel@...ts.sourceforge.net,
	greg@...ah.com, davem@...emloft.net
Cc:	linux-usb-users@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [linux-usb-devel] OHCI root_port_reset() deadly loop...

> From: Greg KH <greg@...ah.com>
>
> Here's some information from Intel about where they have seen this
> happen for UHCI controllers, so it's not just an OHCI issue :(
>
>	...
>
> 1) We see that the ports with low speed devices are still in EHCI mode
> (port owner bit not written to in EHCI driver). In our analyzer captures
> we see the reads from the Port Status & Control register and it is
> indicating that there are low speed devices on the ports. Can you tell
> us why the driver would not be doing the write to the port owner bit
> when it sees that low speed devices are attached to that port? Is there
> something specific that it looks for and decides not to do the write?

It's hard to say without more info about what's going on.  It
might be on a non-enumeraton code path -- where nothing expects
to set the OWNER bit -- or the CONNECT bit might not be set.
See host/ehci-hub.c for details about exactly what the EHCI parts
are doing, and core/hub.c for how it's driven.

(It can be tricky to make sense of all that, easier if debugging
messages are turned on.   But that changes timings.  Better yet
would be being non-intrusive tracing of the actual code paths
that the CPU follows.)


> 2) In other cases we see that the ports with the low speed devices are
> back in UHCI mode but the ports are disabled. In this case we see from
> the analyzer traces that the UHCI driver has completed setting up the
> port. It has actually enabled that port in UHCI mode. We then see the
> EHCI driver comes in and it resets everything. The driver then gives
> control back to the UCHI controller (by setting the port owner bit)
> but...since the UHCI driver has already setup this port once it seems
> that it does not go back and set it up again. In this case we do not
> think that the UHCI driver has completed running when the EHCI driver
> comes in and does the reset. Can you tell us if the UHCI driver was
> interrupted in the middle but after the ports with the low speed devices
> had been enabled would the UHCI driver ever go back and reinitialize the
> ports with the low speed devices?

If the UHCI driver got disconnect and reconnect notifications,
I expect it would do so.  At least OHCI seems *not* to have gotten
such notifications.  I'm speculating that the "just a switch"
behavior for the CF (and OWNER) bits may not allow notifications
like that to happen when the companion controllers are resetting.

- Dave

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