linux-kernel - Re: [PATCH 1/8] PM: Opportunistic suspend support.

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:	Fri, 21 May 2010 22:47:40 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Arve Hjønnevåg <arve@...roid.com>
cc:	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <len.brown@...el.com>,
	Pavel Machek <pavel@....cz>,
	Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Tejun Heo <tj@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nigel Cunningham <nigel@...onice.net>,
	Ming Lei <tom.leiming@...il.com>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	<linux-doc@...r.kernel.org>
Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support.

On Fri, 21 May 2010, [UTF-8] Arve HjÃ¸nnevÃ¥g wrote:

> The first goal can be achieved either by using device runtime PM and
> cpuidle to put all hardware into low-power states, transparently from
> the user space point of view, or by suspending the whole system.
> However, system suspend, in its current form, does not guarantee that
> the events of interest will always be responded to, since wakeup
> events (events that wake the CPU from idle and the system from
> suspend) that occur right after initiating suspend will not be
> processed until another possibly unrelated event wakes the system up
> again.

Minor point of clarification here.  I'm not requesting that the patch 
description be rewritten.  But this issue of lost wakeup events is more 
subtle than it appears.

Wakeup events can be lost in at least three different ways:

     1. A hardware signal (such as an IRQ) gets ignored.

     2. The hardware event occurs, but without effect since the
	kernel thread that would handle the event has been frozen.
	The event just ends up sitting in a queue somewhere until
	something else wakes up the system.

     3. The hardware event occurs and the kernel handles it fully,
	but the event propagates to userspace for further handling
	and the user program is already frozen.

1 is a hardware configuration failure (for example, it might happen as
a result of using edge-triggered IRQs instead of level-triggered) and
is outside the scope of this discussion.

2 generally represents a failure of the core PM subsystem, or a failure
of some other part of the kernel to use the PM core correctly.  In
theory we should be able to fix such mistakes.  Right now I'm aware of
at least one possible failure scenario that could be fixed fairly
easily.

3 is the type of failure that suspend blockers were really meant to
handle, particularly the userspace suspend-blocker API.

IMO, we should strive to fix the existing type-2 failure modes.  
However it is worth pointing out that they are basically separate from 
the suspend-blocker mechanism.

And it might be a good idea to point out somewhere in the patch
descriptions that suspend blockers are really meant to handle type-3
wakeup losses.

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/