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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ