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:	Tue, 25 May 2010 14:08:03 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Arve Hjønnevåg <arve@...roid.com>,
	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 Tue, 25 May 2010, Dmitry Torokhov wrote:

> > > I don't see a big difference between 2 and 3. You can use suspend
> > > blockers to handle either.
> > 
> > You can, but they aren't necessary.  If 2 were the only reason for 
> > suspend blockers, I would say they shouldn't be merged.
> > 
> > Whereas 3, on the other hand, can _not_ be handled by any existing
> > mechanism.  3 is perhaps the most important reason for using suspend
> > blockers.
> > 
> 
> I do not see why 3 has to be implemented using suspend blockers either.
> If you are concerned that event gets stuck somewhere in the stack make
> sure that devices in the stack do not suspend while their queue is not
> empty. This way if you try opportunistic suspend it will keep failing
> until you drained all important queues.

Here's the scenario:

The system is awake, and the user presses a key. The keyboard driver
processes the keystroke and puts it in an input queue.  A user process
reads it from the event queue, thereby emptying the queue.

At that moment, the system decides to go into opportunistic suspend.  
Since the input queue is empty, there's nothing to stop it.  As the
first step, userspace is frozen -- before the process has a chance to
do anything with the keystroke it just read.  As a result, the system
stays asleep until something else wakes it up, even though the
keystroke was important and should have prevented it from sleeping.

Suspend blockers protect against this scenario.  Here's how:

The user process doesn't read the input queue directly; instead it 
does a select or poll.  When it sees there is data in the queue, it 
first acquires a suspend blocker and then reads the data.

Now the system _can't_ go into opportunistic suspend, because a suspend
blocker is active.  The user process can do whatever it wants with the
keystroke.  When it is finished, it releases the suspend blocker and
loops back to the select/poll call.

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/