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]

Message-ID: <alpine.LFD.2.00.1006031630300.8175@i5.linux-foundation.org>
Date:	Thu, 3 Jun 2010 16:37:02 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	tytso@....edu, Brian Swetland <swetland@...gle.com>,
	Neil Brown <neilb@...e.de>, Arve Hj?nnev?g <arve@...roid.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	Peter Zijlstra <peterz@...radead.org>,
	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>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Kevin Hilman <khilman@...prootsystems.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: suspend blockers & Android integration

On Fri, 4 Jun 2010, Ingo Molnar wrote:
> 
>    This allows a task to 'exclude' other tasks that dont have low-latency 
>    requirements. Crappy apps would have a large latency value, so they'd
>    be idled out when a privileged task sets the exclusion level low enough.

Quite frankly, this sounds fundamentally broken.

Think deadlock. The high-latency task got a lock, and now you're excluding 
it because it scheduled away.

So from my perspective, putting that kind of logic deep in the system 
sounds like the _last_ thing we want to do.

I think it's much saner to have a very targeted suspend blocker that only 
blocks the opportunistic suspends and has _zero_ interaction with the rest 
of the system (certainly none at all with core code like the scheduler).

And if somebody then suspends the traditional way (by an actual suspend 
event, not that opportunistic thing), then the suspend blocker does 
nothing at all - because it simply doesn't even _exist_ at that level. 
It's only about the opportunistic suspends.

(I'd further suggest that disk wait and running in kernel mode disable any 
opportunistic suspend anyway - but that's not about suspend blockers as 
much as it is about just the opportunistic suspend itself).

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