Re: linux-next: percpu tree build warning

Ingo Molnar
2009-11-27T05:41:53Z

* 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