linux-kernel - Re: [PATCH, v10 3/3] cgroups: introduce timer slack controller

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: <1318864870.4172.61.camel@twins>
Date:	Mon, 17 Oct 2011 17:21:10 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Lennart Poettering <mzxreary@...inter.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Paul Menage <menage@...gle.com>,
	Li Zefan <lizf@...fujitsu.com>,
	containers@...ts.linux-foundation.org,
	jacob.jun.pan@...ux.intel.com, linux-kernel@...r.kernel.org,
	Matt Helsley <matthltc@...ibm.com>, linux-api@...r.kernel.org,
	Kay Sievers <kay.sievers@...y.org>, harald@...hat.com,
	david@...ar.dk, greg@...ah.com
Subject: Re: [PATCH, v10 3/3] cgroups: introduce timer slack controller

On Mon, 2011-10-17 at 16:19 +0100, Matthew Garrett wrote:
> On Mon, Oct 17, 2011 at 05:11:00PM +0200, Peter Zijlstra wrote:
> > On Mon, 2011-10-17 at 15:59 +0100, Matthew Garrett wrote:
> > > I'm not saying that it's a problem. I'm saying that your approach 
> > > changes behavioural semantics in a way that may violate application 
> > > expectations just as surely as changing the timer behaviour does. 
> > > There's no free approach.
> > 
> > I'm not saying its free, I'm saying its a much better approach since it
> > gets rid of the entire problem instead of papering over the worst of it.
> 
> It solves it for a specific case, ie animations. Any other timer driven 
> behaviour continues. It really does need to be tied to session idle, not 
> application visibility, and enforcement at the X level does nothing to 
> help that.

Well what other cases are there? Can we enumerate them and come up with
similar solutions?

Hard enforcement is very much better than papering over because it makes
the individual developer instantly aware that he's got a problem.
--
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/