linux-kernel - Re: [PATCH 2/7] sched: Update rq clock on nohz CPU before setting fair group shares

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, 10 Apr 2013 13:47:07 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	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>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Paul Turner <pjt@...gle.com>, Mike Galbraith <efault@....de>
Subject: Re: [PATCH 2/7] sched: Update rq clock on nohz CPU before setting
 fair group shares

On Wed, 2013-04-10 at 13:06 +0200, Ingo Molnar wrote:

> There's just a handful of high level entry points, right? schedule(), wakeup, 
> scheduler tick, maybe notifiers - anything else? 

I suppose there's some cgroup muck and the various system calls; most
of them should be covered if we take some lower level primitives or so.

We could 'simply' hijack rq->lock and clear the state every time we
acquire or release it.. maybe have an exemption for the balance double
lock ops.

> Documenting/listing those would 
> be nice anyway, near the top of kernel/sched/core.c or so.

Sure and it might have to do.. I just prefer an option that's less
prone to human failure; being both paranoid and lazy :-)

> The other approach would be to periodically clear the flag from the timer tick. 
> That would catch invalid rq->clock use probabilistically.

Right, but once we have the most common paths covered it is very very
unlikely we'll hit the weird corner cases like this. But it is an
option.

> > I'd clear at the beginning, but that's more or less the same thing.
> > 
> > We have the .sched.text section but I'm not sure we've been consistent enough 
> > with that to be useful. But otherwise we'd be able to clear on section 
> > entry/exit or so.
> 
> Hm, I'm not sure that can be made to work sanely.

Yeah.. one option is to make all code in kernel/sched/ part of
.sched.text but that might be overkill -- not to mention we'd have to
peel things like completions and wait_queues out of sched/kernel/core.c
but that seems like a good idea anyway.

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