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, 20 Feb 2009 22:02:46 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Kyle Moffett <kyle@...fetthome.net>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Alan Stern <stern@...land.harvard.edu>,
	"Woodruff, Richard" <r-woodruff2@...com>,
	Arjan van de Ven <arjan@...radead.org>,
	Oliver Neukum <oliver@...kum.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Pavel Machek <pavel@....cz>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	mark gross <mgross@...ux.intel.com>,
	Uli Luckas <u.luckas@...d.de>,
	Igor Stoppa <igor.stoppa@...ia.com>,
	Brian Swetland <swetland@...gle.com>,
	Len Brown <lenb@...nel.org>
Subject: Re: [RFD] Automatic suspend

On Friday 20 February 2009, Rafael J. Wysocki wrote:
> On Friday 20 February 2009, Kyle Moffett wrote:
> > On Fri, Feb 20, 2009 at 10:56 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> > > * Introduce /sys/power/sleep that will work like /sys/power/state, but:
> > >  - First, it will call ->acknowledge() for each driver (via bus types) to
> > >    check if any of them wants to postpone the suspend (this will prevent tasks
> > >    from being frozen unnecessarily if it is known in advance that the suspend
> > >    should not happen at the moment).
> > >  - Next, it will check the "I_do_not_want_automatic_suspend_to_occur" flag
> > >    of each process and the suspend will be aborted if it is true for any of
> > >    them (quite frankly, I think that should be integrated with the freezer,
> > >    in particular the tasks that have TIF_FREEZE set shouldn't be able to set
> > >    this flag and it should be checked in the freezer loop for every task with
> > >    TIF_FREEZE unset).
> > >  - Next, it will proceed with suspending just like /sys/power/state does (the
> > >    drivers that missed the opportunity to abort the suspend by returning
> > >    'false' from ->acknowledge() can still abort the suspend by failing their
> > >    ->suspend() routines).
> > >
> > > Then, the decision making logic will be able to use /sys/power/sleep whenever
> > > it wishes to and the kernel will be able to refuse to suspend if it's not
> > > desirable at the moment.
> > 
> > Then, for a userspace process handling input events:
> > 
> > 1)  Unset "no-suspend flag"
> > 2)  Poll event device
> > 3)  When the poll returns true, set the "no-suspend flag"
> > 4)  Read the event device and process the event(s)
> > 5)  Go back to step 1
> > 
> > The event driver would responsible for atomically preventing suspend
> > from the moment a button is pressed until it is actually delivered to
> > a userspace process.  Since at that time the userspace process will be
> > preventing suspend, there will be no window in which we could go to
> > sleep with pending events.
> 
> That's correct.
> 
> How would you like to prevent it from happening?

To clarify, we're talking about automatic suspend only.  The "old" suspend
interface is going to stay so that one can force suspend (or hibernation) to
happen.

Thanks,
Rafael
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ