On Thu, Jul 30, 2020 at 11:03:40AM -0700, Nick Desaulniers wrote:
> From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
>
> commit 59b6359dd92d18f5dc04b14a4c926fa08ab66f7c upstream.
>
> If CONFIG_DEBUG_LOCK_ALLOC=y, the kernel log is spammed with a few
> hundred identical messages:
>
> unwind: Unknown symbol address c0800300
> unwind: Index not found c0800300
>
> c0800300 is the return address from the last subroutine call (to
> __memzero()) in __mmap_switched(). Apparently having this address in
> the link register confuses the unwinder.
>
> To fix this, reset the link register to zero before jumping to
> start_kernel().
>
> Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
> Suggested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> Acked-by: Nicolas Pitre <nico@xxxxxxxxxx>
> Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxx>
> Signed-off-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx>
> ---
> Looks like this first landed in v4.15-rc1. Without this, we can't tell
> during an unwind initiated from start_kernel() when to stop unwinding,
> which for the clang specific implementation of the arm frame pointer
> unwinder leads to dereferencing a garbage value, triggering an exception
> which has no fixup, triggering a panic, triggering an unwind, triggering
> an infinite loop that prevents booting. I have more patches to send
> upstream to make the unwinder more resilient, but it's ambiguous as to
> when to stop unwinding without this patch.
Note, the "Fixes:" tag points at something in 4.15, not 4.14, so are you
_SURE_ this is needed in 4.14.y?
thanks,
greg k-h
