linux-kernel - Re: [ANNOUNCE] 3.9-rc1-nohz1

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:	Mon, 11 Mar 2013 08:39:09 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Alessio Igor Bogani <abogani@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Metcalf <cmetcalf@...era.com>,
	Christoph Lameter <cl@...ux.com>,
	Geoff Levand <geoff@...radead.org>,
	Gilad Ben Yossef <gilad@...yossef.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Li Zhong <zhong@...ux.vnet.ibm.com>,
	Namhyung Kim <namhyung.kim@....com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Kevin Hilman <khilman@...aro.org>,
	Mats Liljegren <mats.liljegren@...a.com>
Subject: Re: [ANNOUNCE] 3.9-rc1-nohz1


* Frederic Weisbecker <fweisbec@...il.com> wrote:

> >  - Please outline how the current TODO entries affect upstream
> >    mergability. Does it reduce the 'full'-ness of this dynticks mode?
> >    Outright buggy behavior? Other trade-offs?
> 
> Mostly this is about upstream features that won't be working with the current 
> state of the art: enqueuing a posix cpu timer on a nohz CPU may result in it being 
> ignored by the target due to the lack of ticking until expiration, perf events may 
> not be round-robined, etc... I'll make sure to document all these items.

So it's "buggy behavior of existing features" it appears?

It would be really useful to add some sort of 'make it safe easily' mechanism:

 - if a posix timer is enqueued on a CPU, then the CPU should have a timer ticking

 - if perf events are active on a CPU, then it should have a timer ticking

this would make it mergable, as most of the time systems don't have any of these 
facilities active. Plus this dynticks-off mechanism would also allow us to cover any 
other (still unknown) facility that regresses. So it would be nice to have that 
option.

Later on we could gradually eliminate these limitations. It would also be apparent 
where they are, just from grepping the source.

If that's done, and if it tests fine for a few weeks then this could be v3.10 
material IMO.

Thanks,

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