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
| ||
|
Date: Sun, 29 Nov 2009 07:40:19 +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 Fri, 27 Nov 2009 04:11:28 pm Ingo Molnar wrote: > > > > * 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. > > That's foolish. We can now have generic per-cpu function for counters > and the like. So your argument in favor of what i see as at least a mild form of type obfusaction is that ... even more obfuscation is upcoming? I think percpu usage should be spelled out clear and loud. We should not pretend they are 'usual' C variables, because they are not. They are defined in a special way, they are used via special operators. I sure want to make sure that taking an address of one of them: ptr = &dr7; ... looks special too. Just look at the two 'fixes' i quoted in this discussion: 28b4e0d: x86: Rename global percpu symbol dr7 to cpu_dr7 11e6635: kernel/hw_breakpoint.c: Fix local/global shadowing They actually 'solved' the shadowing by renaming the variables to ... cpu_. Think about it: the 'I am percpu' prefix came right back - it's just now present in a more volatile form and the default usage is slightly more dangerous! I guess i'm a bit more sensitive to percpu complications than you because i've seen my fair share of bugs in the scheduler (and preemptible/non-preemptible code) related to percpu code (a fair share of it introduced by yourself ;-), so the last thing i'd like to see is changes that are hiding its nature. I _use_ percpu code, i dont just write the facilities ;-) > [...] Again, I'm explaining what you should already know before > sending email about this stuff. > [...] > Stupidest debate ever. What i am making is a somewhat subtle technical argument and making any progress on it needs at least a minimal form of a working debate. I do not claim i am right, but still you are dismissing my arguments in a rather nasty way. ... alas, i dont care _that_ much about this and i dont think my concerns deserved your ad hominem attacks so i see no point in further participating in this thread. Thanks, 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/
Powered by blists - more mailing lists