linux-kernel - Re: suspend blockers & Android integration

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:	Sat, 5 Jun 2010 18:24:43 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, tytso@....edu,
	Brian Swetland <swetland@...gle.com>,
	Neil Brown <neilb@...e.de>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: suspend blockers & Android integration

2010/6/5 Thomas Gleixner <tglx@...utronix.de>:
> On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/5 Thomas Gleixner <tglx@...utronix.de>:
>> >> > Well, that's simply an application bug which sucks battery with or
>> >> > without suspend blockers. So it's unrelated to the freezing of
>> >> > untrusted apps while a trusted app still works in the background
>> >> > before allowing the machine to suspend.
>> >> >
>> >>
>> >> It is not unrelated if the trusted app has stopped working but still
>> >> blocks suspend. The battery drains when you combine them.
>> >
>> > What you are describing is a problem which is not solvable either way.
>> > If you take the lock and do not release it you're not going to
>> > suspend. I never claimed that any other mechanism resolves this.
>> >
>> Whether you claimed it or not, this is the only case where using
>> cgroups would have a significant power saving over what we get with
>> suspend. The trusted app is idle and the untrusted app is frozen, so
>> we enter a low power mode from idle.
>
> Nothing else was what I said and depending on the usage pattern this
> can be significant. Just you converted a perfectly sensible technical
> argument into a quibble about BUGs in applicatins which are not
> confinable by defintion.
>
>> > But this is not related to the fact that freezing crap while running a
>> > sane background task is going to save you power vs. an approach where
>> > running a sane background task allows crap to consume power unconfined
>> > until it is done.
>> >
>> If the task that is blocking suspend is using the cpu anyway, then the
>> bad app does not increase the power consumption nearly as much as if
>> the task that blocked suspend is idle.
>
> That's utter bullshit. If the app missed to release the supsend
> blocker then your crappy "while(1);" app is killing you in no time,
> while the same frozen crappy "while(1);" does no harm at all.
>
This is the bug I described above. If the app that blocked suspend did
not release the suspend blocker and went idle, then another while(1)
app will drain the battery. If the app that blocked suspend only
blocked suspend while it needs to run (which is the typical reason to
block suspend) then the system is not idle anyway and the impact of
the while(1) app is much less severe.

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