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/
