linux-kernel - Re: [RFC][PATCH -mm 3/3] PM: Disable _request

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:	Mon, 28 May 2007 12:43:36 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Matthew Garrett <mjg59@...f.ucam.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Pavel Machek <pavel@....cz>, Oliver Neukum <oliver@...kum.org>
Subject: Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before
 hibernation/suspend

On Mon, 28 May 2007, Matthew Garrett wrote:

> On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
> 
> > I can't speak for the second example, but there's a good reason the
> > first example works this way.  It's not a matter of races; the problem
> > is that the kernel thread's job is to selectively suspend and resume
> > devices.  We don't want it doing this while a system sleep is in 
> > progress; it would (and in fact has, before the thread was made 
> > freezable) cause the sleep transition to abort.
> 
> How does this work on PPC or APM systems?

For hibernation it behaves the same as on other types of systems.

For STR it generally works okay.  There was one report of suspends
aborting, and it looked like this was caused by selective resumes
originating from userspace.  This seemed to be unrelated to the kernel
threads; apparently some program was running while the STR was in
progress, and causing the problem.  For example, the lsusb program will
do a selective resume on every USB device as it scans through them all.
However that's just a guess, we haven't fully resolved that bug report.

The theoretical answer is that it behaves the way we want.  The kernel 
thread does selective resumes in response to device requests.  If such 
a request comes in while the system is asleep it will awaken the 
system; so it's only logical that a request coming in while the system 
is in the process of going to sleep should abort the suspend.

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/