linux-kernel - Re: [PATCH 0/6] [RFC] Proposal for optimistic suspend idea.

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]

Message-ID: <1317200359.5781.47.camel@twins>
Date:	Wed, 28 Sep 2011 10:59:19 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	John Stultz <john.stultz@...aro.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, arve@...roid.com,
	markgross@...gnar.org, Alan Stern <stern@...land.harvard.edu>,
	amit.kucheria@...aro.org, farrowg@...ibm.com,
	"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
	linux-pm@...ts.linux-foundation.org, khilman@...com,
	Magnus Damm <damm@...nsource.se>, mjg@...hat.com,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/6] [RFC] Proposal for optimistic suspend idea.

On Tue, 2011-09-27 at 15:56 -0700, John Stultz wrote:
> 
> But I also want to separate my specific solution from the problem at
> large. I do think that there are issues that my proposal and wakelocks
> address that the hand-wavy "just do it in userspace" rebuttals don't
> deal with (again specifically: wakeup event consumption in userland
> before the next suspend). 

You know, once you drop the whole suspend notion that race goes away.

Esp. on the mobile hardware there really isn't anything different
between a deep idle state and suspend.

So just make the thing idle and your suspend race goes away.

There's still things like the cgroup-freezer if you really want to force
stuff down, but really your core system should be sane and not actually
do anything unless asked.

Also, I'm all for aggressive enforcement, if it doesn't obey they rules,
kill it. Don't mess about with freezing it, that never does the users
any favour.

If they find their app dies a lot, they'll complain to the dev, if the
dev doesn't fix his stuff, the app gets a shitty rating and nobody will
bother installing it again, problem sorted.

We don't try to be friendly in the face of memory protection violations
either.
--
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/