linux-kernel - Re: linux-next: percpu tree build warning

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: <20091127054128.GC13914@elte.hu>
Date:	Fri, 27 Nov 2009 06:41:28 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Tejun Heo <tj@...nel.org>, Stephen Rothwell <sfr@...b.auug.org.au>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Lameter <cl@...ux-foundation.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: linux-next: percpu tree build warning

* Rusty Russell <rusty@...tcorp.com.au> wrote:

> On Thu, 26 Nov 2009 12:10:58 am Ingo Molnar wrote:
> > While a percpu variable is defined and used in completely different 
> > ways:
> > 
> >   DEFINE_PER_CPU(unsigned long, dr7);
> > 
> > and is used via:
> > 
> >   __get_cpu_var(dr7);  [[Fixed -- RR]]
> 
> The entire point of Tejun's per-cpu work is that &dr7 is now valid. A 
> per-cpu pointer as if it were allocated by the dynamic per-cpu 
> allocator.
>
> Your arguments are fine, but out-of-date.

But allowing &dr7 is outright dangerous - and not particularly clean 
either.

Nothing tells us that it's a percpu variable and it blends into the 
regular namespace while most of the operators on it are special 
(__get_cpu_var(), per_cpu(), __this_cpu(), etc.).

What if someone writes &dr7 in preemptible code? It's dangerous to do it 
and a quick review wont catch the mistake. Seeing &per_cpu_dr7 in 
clearly preemptible code does raise alarms on the other hand.

So i think it should be valid to take the address of it and unify the 
static and dynamic percpu space ... if it's prefixed properly: what's 
wrong with &per_cpu_dr7?

Either make it fully blend in or keep it separate - but dont do it 
half-ways, that's only causing confusion down the road. Furthermore, i 
think per cpu logic and code is tricky enough to be documented clearly, 
every time it's used. We have bugs with such code again and again, and 
disproportionately so.

So AFAICS this change is going in exactly the wrong direction, makes the 
percpu code less readable and more obstructed and more inconsistent, and 
does it for all the wrong reasons and is causing some collateral damage 
as well.

	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/