linux-kernel - Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 7 May 2010 09:25:44 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	James Kosin <james.kosin.04@....edu>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

* James Kosin <james.kosin.04@....edu> [100506 20:14]:
> On 5/6/2010 11:10 PM, Arve Hjønnevåg wrote:
> >>>>         
> >>> One if the benefit we get from using suspend is that an unprivileged
> >>> app that does not have access to suspend blockers cannot prevent
> >>> suspend. You lose this advantage if you trigger suspend only from the
> >>> idle task.

This assumes that you're using cached values for echo mem > /sys/power/state
and the system keeps on running.

IMHO if you want to keep the system running, then you should just use
cpuidle and implement good idle modes.

Then when someting in the userspace knows you've been idle long enough,
you can suspend.

> >> If the process (privileged or unprivileged) doesn't want to suspend, why
> >> not just provide an interface to allow suspend to be turned off at the
> >> user level.  This could block the suspend cycle in itself, and you
> >> shouldn't need fine grained off/on cycles.  If an application really
> >> needs the system not to suspend then they (the user) should know the
> >> consequences and power requirements for such a task.
> >>
> >> I didn't say it had to be only from the idle task; but, that is the most
> >> logical place.  If the other threads are not idle then they really
> >> require work and will most likely already have a bock on the suspend anyway.
> >>
> >>     
> > I think you missed my point. Unprivileged processes should not be
> > allowed to prevent suspend.

You could just freeze the GUI process based on some policy if you
worry about misbehaving timers in various apps. This way the cpuidle
modes will allow you to run some userspace policy daemon. And then that
can suspend if needed based on how it's configured.
  
> Ah, you want a way for the system to suspend (and enforce the suspend)
> when only unprivileged processes are the only thing running....
> 
> That would mean a lot of work defining the unprivileged (or privileged)
> processes, and properly suspending (or enforcing) when needed.  Yuck. 
> Sorry I commented then, this is really getting deep into what I love to
> do at work.

Hmm, yeah sounds a bit messy.

Tony
--
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/