linux-kernel - Re: [PATCH 2/8] PM: Asynchronous suspend and resume of devices

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:	Sun, 24 Jan 2010 17:30:21 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	<linux-usb@...r.kernel.org>, Greg KH <gregkh@...e.de>,
	Arjan van de Ven <arjan@...radead.org>,
	Nigel Cunningham <ncunningham@...a.org.au>
Subject: Re: [PATCH 2/8] PM: Asynchronous suspend and resume of devices

On Sun, 24 Jan 2010, Rafael J. Wysocki wrote:

> > There needs to be a public interface to this function available for 
> > drivers that have non-tree constraints.  The arguments should be the 
> > device to wait for and the device doing the waiting (needed only to 
> > determine whether the caller is running synchronously or not).
> 
> Something like the patch below?

Yes, exactly.  Thanks.

> > This will be necessary for USB.  In fact, your current code (with patch 
> > 7/8 applied) is subject to a race that will sometimes cause a 
> > non-high-speed USB device to fail to resume from hibernation.
> 
> That's the kind of information I need at this point.  What exactly should be
> added to patch 7/8 to avoid this problem?

I don't think there's anything you can do about it, really.  It's an
obscure USB issue: If an EHCI controller was reset or loses power
during a system sleep (which always happens with hibernation and
sometimes happens with suspend-to-RAM, depending on the chipset and
firmware), then the EHCI controller must be resumed after all its
sibling companion OHCI/UHCI controllers, and USB devices below the
companion root hubs must be resumed after the EHCI root hub.

With synchronous resume this happens automatically because the devices
in question are always registered in the appropriate order.  But the
only way to meet these constraints with async resume is to add specific
code to the USB core to enforce the non-tree orderings.

I intend to write this code, but merging it will be a little tricky.  
You'll have to coordinate with Greg KH.

If you have a non-high-speed USB device, you can test to see if this
problem is not just a figment of my imagination.  To violate the first
constraint, add an ssleep(1) to the beginning of ohci_pci_resume() in
drivers/usb/host/ohci-pci.c or to the beginning of uhci_pci_resume() in
drivers/usb/host/uhci-hcd.c (depending on whether your companion
controllers are OHCI or UHCI).  To violate the second constraint, add
an ssleep(1) to the beginning of ehci_bus_resume() in
drivers/usb/host/ehci-hub.c.  Either constraint violation should cause
the device to be disconnected and then reconnected during an async
resume from hibernation, as opposed to simply being reset.

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/