openwrt/target/linux/generic/backport-5.4/310-v5.6-mips-vdso-fix-jalr-t9-crash-in-vdso-code.patch
Tony Ambardar 2932b4d05e kernel: mips: fix init crash/bootloop on 64-bit systems
The malta subtargets for mips64 and mips64el fail to start the init process
at boot, resulting in a boot loop. The issue was raised and analyzed within
FS#3277. Investigation suggested code near the [vdso] memory area of the
process was long jumping into a region inaccessible to the process, e.g.

 init: - preinit -
 init: Launched preinit instance, pid=522
 do_page_fault(): sending SIGSEGV to init for invalid read access from 0000000000000360
 epc = 0000000000000360 in init[aaab42b000+4000]
 ra  = 000000fffee385e0 in
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
 Rebooting in 1 seconds..

Note the low-memory read access and epc are the same. Upstream kernel 5.6
included a relevant patch and discussion:

  * d3f703c4359f ("mips: vdso: fix 'jalr t9' crash in vdso code")

Disassembly of the failing kernel's vdso.so confirmed presence of the
telltale long jumps, e.g.:

00000000000007c0 <__vdso_clock_getres@@LINUX_2.6>:
 [...]
 7dc:   0320f809        jalr    t9
 [...]

Restore booting mips64/mips64el malta by backporting the above commit:
  * 310-v5.6-mips-vdso-fix-jalr-t9-crash-in-vdso-code.patch

Fixes: 54310a3aa0 ("malta: add kernel 5.4 config")
Fixes: FS#3277
Ref: https://bugs.openwrt.org/index.php?do=details&task_id=3277

Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
2020-08-15 00:04:59 +08:00

60 lines
2.6 KiB
Diff

From d3f703c4359ff06619b2322b91f69710453e6b6d Mon Sep 17 00:00:00 2001
From: Victor Kamensky <kamensky@cisco.com>
Date: Tue, 11 Feb 2020 11:24:33 -0800
Subject: [PATCH] mips: vdso: fix 'jalr t9' crash in vdso code
Observed that when kernel is built with Yocto mips64-poky-linux-gcc,
and mips64-poky-linux-gnun32-gcc toolchain, resulting vdso contains
'jalr t9' instructions in its code and since in vdso case nobody
sets GOT table code crashes when instruction reached. On other hand
observed that when kernel is built mips-poky-linux-gcc toolchain, the
same 'jalr t9' instruction are replaced with PC relative function
calls using 'bal' instructions.
The difference boils down to -mrelax-pic-calls and -mexplicit-relocs
gcc options that gets different default values depending on gcc
target triplets and corresponding binutils. -mrelax-pic-calls got
enabled by default only in mips-poky-linux-gcc case. MIPS binutils
ld relies on R_MIPS_JALR relocation to convert 'jalr t9' into 'bal'
and such relocation is generated only if -mrelax-pic-calls option
is on.
Please note 'jalr t9' conversion to 'bal' can happen only to static
functions. These static PIC calls use mips local GOT entries that
are supposed to be filled with start of DSO value by run-time linker
(missing in VDSO case) and they do not have dynamic relocations.
Global mips GOT entries must have dynamic relocations and they should
be prevented by cmd_vdso_check Makefile rule.
Solution call out -mrelax-pic-calls and -mexplicit-relocs options
explicitly while compiling MIPS vdso code. That would get correct
and consistent between different toolchains behaviour.
Reported-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: richard.purdie@linuxfoundation.org
---
arch/mips/vdso/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index aa89a41dc5dd..848baeaef1f8 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -33,6 +33,7 @@ endif
cflags-vdso := $(ccflags-vdso) \
$(filter -W%,$(filter-out -Wa$(comma)%,$(KBUILD_CFLAGS))) \
-O3 -g -fPIC -fno-strict-aliasing -fno-common -fno-builtin -G 0 \
+ -mrelax-pic-calls -mexplicit-relocs \
-fno-stack-protector -fno-jump-tables -DDISABLE_BRANCH_PROFILING \
$(call cc-option, -fno-asynchronous-unwind-tables) \
$(call cc-option, -fno-stack-protector)
--
2.17.1