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:	Wed, 26 May 2010 18:12:22 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	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>,
	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 Wed, 26 May 2010, Rafael J. Wysocki wrote:

> > The reason is simple: When a user process initiates an opportunistic 
> > suspend, you make it wait in an interruptible sleep until all the 
> > kernel suspend blockers are released.  No polling.  If another user 
> > thread decides in the meantime that it needs to block the suspend, it 
> > sends a signal to the power manager process.
> > 
> > In fact, other threads should signal the power manager process whenever 
> > they want to block or unblock suspends.  That way the power manager 
> > process can spend all its time sleeping, without doing any polling.
> 
> I still see an issue here.  Namely, if the power manager is in user space and
> it's signaled to suspend, it has to ask the kernel to do that, presumably by
> writing something to a sysfs file.  Then, if the kernel blocks the suspend, the
> power manager waits until the block is released.  Now, it should go back and
> check if user space still doesn't block suspend and if so, wait until the block
> is released and start over.  With all suspend blockers in the kernel this
> looping behavior is avoidable.

I must be missing something.  In Arve's patch 1/8, if the system is in
opportunistic suspend, and a wakeup event occurs but no suspend
blockers get enabled by the handler, what causes the system to go back
into suspend after the event is handled?  Isn't that a loop of some
sort?

And even if it isn't, so what?  What's wrong with looping behavior?  
Especially a loop that's as short as this one and spends almost all of
its time sleeping.  Think how much harder it would be to write programs
if you weren't allowed to use any loops.  :-)

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/