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]

Message-Id: <201001250027.42621.rjw@sisk.pl>
Date:	Mon, 25 Jan 2010 00:27:42 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
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 Sunday 24 January 2010, Alan Stern wrote:
> 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.

OK, I'll put it into the patchset after 5/8.

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

OK, I don't think that's a big deal.  I can defer patch 7/8 until that code has
been merged.

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

I'll try that, but my mkinitrd automatically puts the USB drivers into
initramfs.  I guess I'll need to do some research to really verify it. :-)

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