linux-kernel - Re: Attempted summary of suspend-blockers LKML thread

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, 3 Aug 2010 18:09:12 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	mjg59@...f.ucam.org, pavel@....cz, florian@...kler.org,
	rjw@...k.pl, stern@...land.harvard.edu, swetland@...gle.com,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Tue, Aug 03, 2010 at 03:23:00PM -0700, Arve Hjønnevåg wrote:
> 2010/8/3 Paul E. McKenney <paulmck@...ux.vnet.ibm.com>:
> > On Mon, Aug 02, 2010 at 09:18:27PM -0700, Arve Hjønnevåg wrote:
> >> On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney
> >> <paulmck@...ux.vnet.ibm.com> wrote:
> ...
> >> > o       Statistics of the power-control actions taken by power-aware
> >> >        applications must be provided, and must be keyed off of program
> >> >        name.
> >>
> >> We don't key the stats off the program name, but having useful
> >> statistics is critical too us. The current code in linux-next does not
> >> appear to allow this (I'm referring to pm_stay_awake here, etc not
> >> pm-qos.)
> >
> > OK, maybe I was confused earlier.  So you do not track statistics via
> > the device being open throughout the application's lifetime?
> 
> The suspend blocker patchset does track statistics while the device is
> open, but it it not keyed of the program name. The name is passed from
> user-space and a single process can have the device open several
> times. The wakelock interface that we currently use just creates a new
> object every time it sees a new name and never frees it.

Ah, good to know!

							Thanx, Paul

> ...
> >> > o       If no power-aware or power-optimized application are indicating
> >> >        a need for the system to remain operating, the system is permitted
> >> >        (even encouraged!) to suspend all execution, even if power-naive
> >> >        applications are runnable.  (This requirement did appear to be
> >> >        somewhat controversial.)
> >>
> >> I would say it should suspend even if power aware applications are
> >> runnable. Most applications do not exclusively perform critical work.
> >
> > The point being that a power-aware application does not block suspend
> > -unless- it holds a suspend blocker, correct?
> 
> Yes.
> 
> >
> > Or am I missing some other subtlety?
> 
> No.
> 
> ...
> >> > o       Any initialization of the API that controls the system power
> >> >        state must be unconditional, so as to be free from failure.
> >> >        (I don't currently understand how this relates, probably due to
> >> >        my current insufficient understanding of the proposed patch set.)
> >>
> >> Unconditional initialization makes it easier to add suspend blockers
> >> to existing kernel code since you don't have to add new failure exit
> >> paths. It is not a strong requirement.
> >
> > Ah, that makes more sense!  I moved this to a new "NICE-TO-HAVES"
> > section.  I also changed the last parenthesized sentence to read
> > "Such unconditional initialization reduces the intrusiveness of the
> > the Android patchset."  Does that work?
> >
> 
> Sure.
> 
> 
> 
> -- 
> Arve Hjønnevåg
--
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/