On 13-02-27 09:57 AM, Linus Torvalds wrote: > On Tue, Feb 26, 2013 at 11:33 PM, Dave Airlie <airl...@gmail.com> wrote: >> >> It looks to me like the weak bit isn't working so well >> >> if (platform_sysrq_reset_seq) { >> for (i = 0; i < ARRAY_SIZE(sysrq_reset_seq); i++) { >> key = platform_sysrq_reset_seq[i]; >> 6d: 66 8b 8c 00 00 00 00 mov 0x0(%eax,%eax,1),%cx >> 74: 00 >> >> is around where it craps out. >> gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) >> Fedora 18 machine. > > Hmm. I would love to blame gcc, but no, I think the code is crap. > > The whole 'platform_sysrq_reset_seq[]' thing is broken in current git, > and it apparently only happens to work by mistake for most of us. > > Doing a "grep" for it shows all three uses: > > git grep platform_sysrq_reset_seq > > extern unsigned short platform_sysrq_reset_seq[] __weak; > if (platform_sysrq_reset_seq) { > key = platform_sysrq_reset_seq[i]; > > and the thing is, if it is declared as an array (not a pointer), then > I think it is perfectly understandable that when then testing the > *address* of that array, gcc just says "you're stupid, you're testing > something that cannot possibly be NULL, so I'll throw your idiotic > test away". > > And gcc would be completely correct. That test is moronic. You just > said that platform_sysrq_reset_seq[] was an external array, there is > no way in hell that is NULL. > > Now, if it was a _pointer_, that would be a different thing entirely. > A pointer can have a NULL value. A named array, not so much. > > So I *think* the fix might be something like the attached. Totally > untested. It may compile, or it may not. > > Linus >
Your fix is compiling, running and yielding the correct results - apologies about that. Acked-by: Mathieu Poirier <mathieu.poir...@linaro.org> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/