linux-kernel - Re: Missing USB XHCI and EHCI reset for kexec

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: <1402180544.3979.3.camel@pasglop>
Date:	Sun, 08 Jun 2014 08:35:44 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Thadeu Lima de Souza Cascardo <cascardo@...ux.vnet.ibm.com>,
	linux-usb <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...el.com>
Subject: Re: Missing USB XHCI and EHCI reset for kexec

On Sat, 2014-06-07 at 11:40 -0400, Alan Stern wrote:

> The current xhci-hcd driver includes a quirk flag (XHCI_SPURIOS_WAKEUP) 
> that causes the shutdown routine to reset the controller.  It wasn't 
> meant for fixing kexec problems, but I bet you could use it for that 
> purpose.
> 
> In addition, it's possible that a reset is needed in the probe pathway.

Looking at the code a bit more ... that xhci_shutdown() worries me.

It basically just whacks xhci_halt() and optionally reset() but nothing
is done that I can see to ensure that we aren't concurrently
doing things like queuing URBs, polling the root hub etc...

That's definitely not clean and while it might work (most of the time
at least) on actual shutdown it's definitely not right for kexec I
reckon.

Now there's a separate discussion that we had a while ago and might
want to resume which is to say that kexec shouldn't be calling
shutdown() anyway, but instead remove() on all drivers which is
a much better code path for the purpose of leaving the device in
a state where a driver can reconnect to it.

However, in the case of XHCI that leads to another issue described
here:

http://marc.info/?l=linux-usb&m=139483181809062&w=2

For which there was little / no discussion at all... I suppose we could
do a quirk but I don't think the problem is fundamentally
specific to the TI chip, we should probably stop both root hubs
before we halt both HCDs.

Cheers,
Ben.

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