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: <Pine.LNX.4.44L0.1001251653140.1733-100000@iolanthe.rowland.org>
Date:	Mon, 25 Jan 2010 17:04:25 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Greg KH <gregkh@...e.de>, LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	USB list <linux-usb@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Nigel Cunningham <ncunningham@...a.org.au>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Linux PCI <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 2/8] PM: Asynchronous suspend and resume of devices

On Mon, 25 Jan 2010, Rafael J. Wysocki wrote:

> > You may have to delay 6/8 as well, since the controllers are PCI
> > devices.  Writing the new code shouldn't take too long, though.
> 
> No problem with that.
> 
> Alternatively, if Greg agrees, I can add your patches modifying this into this
> series.  Greg?
> 
> I wonder, though.  Since the controllers are PCI devices, we put them into D0
> and restore their standard config spaces in the dpm_list order at the "early"
> resume stage.  Doesn't that help here?

No.  The problem is that the "late" resume routines in the host
controller drivers reinitialize the hardware, and existing connections
(i.e., from before the system sleep) may not be handled properly if the
controllers are initialized in the wrong order.


> > > 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. :-)
> > 
> > Then when you install the test kernel, mkinitrd should build a
> > corresponding initramfs image with the modified drivers, right?  
> > Otherwise there would be a version mismatch error when the init code
> > tried to load the old drivers into the new kernel.
> 
> Yes, but then they are loaded during restore before the image is read and
> the hardware is initialized.  Would it still fail in that case?

It wouldn't matter.  What the boot kernel does shouldn't affect what 
happens after the image starts running.

BTW, I should mention that these problems don't always occur 100% of 
the time, even when the order constraints are violated.  There may
still be other races that can affect the result.  But try it and see...

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/