Re: linux-next: percpu tree build warning

[Ingo Molnar <mingo@elte.hu>]

* Rusty Russell <rusty@rustcorp.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