modules fix incorrect percpu usage
in [Kernel]
|
From: Tejun Heo on 30 Mar 2010 22:00 On 03/30/2010 10:52 PM, Mathieu Desnoyers wrote: > Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed > for per cpu pointers). > > Introduced by commit: > > module.c: commit 6b588c18f8dacfa6d7957c33c5ff832096e752d3 > > It applies to mainline as of 2.6.34-rc2. This patch should be queued for the > stable branch, for kernels 2.6.29.x to 2.6.33.x. > (based on 2.6.33.1, also applies to 2.6.34-rc2 -tip) > > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> > CC: Randy Dunlap <randy.dunlap(a)oracle.com> > CC: Eric Dumazet <dada1(a)cosmosbay.com> > CC: Rusty Russell <rusty(a)rustcorp.com.au> > CC: Peter Zijlstra <a.p.zijlstra(a)chello.nl> > CC: Tejun Heo <tj(a)kernel.org> > CC: Ingo Molnar <mingo(a)elte.hu> > CC: Andrew Morton <akpm(a)linux-foundation.org> > CC: Linus Torvalds <torvalds(a)linux-foundation.org> > CC: Greg Kroah-Hartman <gregkh(a)suse.de> > CC: Steven Rostedt <rostedt(a)goodmis.org> > CC: stable <stable(a)kernel.org> Acked-by: Tejun Heo <tj(a)kernel.org> Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steven Rostedt on 30 Mar 2010 22:10 On Tue, 2010-03-30 at 16:24 -0400, Mathieu Desnoyers wrote: > > Why do you beleive this should be backported to -stable? What are the > > user-visible effects of this change? > > > > As for the user-visible impact of this specific patch, I guess nobody noticed > any problem because we've been lucky enough that the compiler did not generate > the inappropriate optimization pattern there. > > This inappropriate use of per_cpu_ptr() elsewhere (in __module_ref_addr() from > module.h) caused a NULL pointer exception on Randy's machine. > > So either we consider that the code is better left untouched, or we apply this > patch to module.c in order to prevent compiler optimizations from subtly > breaking the generated assembly with specific configurations of the current or > future versions of the compiler. At that level, it becomes a policy question > about what should go in -stable, for which I will defer to Greg and you. I would > perfectly understand if you consider that it does not belong to -stable, because > there is no perceived user impact so far. I don't know. A possible "NULL pointer dereference" seems to me to be a pretty big user visible impact. I guess the question is, what's the risk of adding this change? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 30 Mar 2010 22:20
On 03/31/2010 11:03 AM, Steven Rostedt wrote: > I don't know. A possible "NULL pointer dereference" seems to me to be a > pretty big user visible impact. > > I guess the question is, what's the risk of adding this change? AFAICS, the risk is fairly low. per_cpu_ptr(pcpudest, cpu) is SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu))) which is just a fancy way of saying "typeof(ptr)((unsigned long)(ptr) + per_cpu_offset(cpu))" with enough obfuscation to prevent gcc from optimizing it incorrectly. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |