(On phone, sorry for top-posting)
Yes, I found that. I don't think its overflowing, more negative (hence the 3ffffff2, which would be fffff88 or something like that for off). Trying with that masked appropriately. If it works I'll send a patch with appropriate BUG_ONs.
James
> On 21 Oct 2016, at 18:26, David Miller <davem@xxxxxxxxxxxxx> wrote:
>
> From: Rob Gardner <rob.gardner@xxxxxxxxxx>
> Date: Fri, 21 Oct 2016 09:49:30 -0600
>
>> That could be either a stray memory write or a boot time patch gone
>> wrong.
>
> It could be that we need to use non-predicting branches in the jump
> label implementation. We could be overflowing the branch displacement
> range if the kernel being built is really huge.
>
> Something like the following would fix it if true:
>
> diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
> index 59bbeff..841d98e 100644
> --- a/arch/sparc/kernel/jump_label.c
> +++ b/arch/sparc/kernel/jump_label.c
> @@ -19,13 +19,8 @@ void arch_jump_label_transform(struct jump_entry *entry,
> if (type == JUMP_LABEL_JMP) {
> s32 off = (s32)entry->target - (s32)entry->code;
>
> -#ifdef CONFIG_SPARC64
> - /* ba,pt %xcc, . + (off << 2) */
> - val = 0x10680000 | ((u32) off >> 2);
> -#else
> /* ba . + (off << 2) */
> val = 0x10800000 | ((u32) off >> 2);
> -#endif
> } else {
> val = 0x01000000;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
