* Rusty Russell <rusty@xxxxxxxxxxxxxxx> 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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
