kernel.git/arch/riscv, branch linux-5.13.y

riscv: dts: microchip: Add ethernet0 to the aliases node

2021-09-08T06:50:20Z

[ Upstream commit 417166ddec020c4e969aea064e23822591ad54df ] U-Boot expects this alias to be in place in order to fix up the mac address of the ethernet node. Note on the Icicle Kit board, currently only emac1 is enabled so it becomes the 'ethernet0'. Signed-off-by: Bin Meng Reviewed-by: Geert Uytterhoeven Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv: dts: microchip: Use 'local-mac-address' for emac1

2021-09-08T06:50:19Z

[ Upstream commit 719588dee26bac0d5979c122bc530c43dc5d07c7 ] Per the DT spec, 'local-mac-address' is used to specify MAC address that was assigned to the network device, while 'mac-address' is used to specify the MAC address that was last used by the boot program, and shall be used only if the value differs from 'local-mac-address' property value. Signed-off-by: Bin Meng Reviewed-by: conor dooley Reviewed-by: Geert Uytterhoeven Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv: Ensure the value of FP registers in the core dump file is up to date

2021-09-03T08:22:47Z

commit 379eb01c21795edb4ca8d342503bd2183a19ec3a upstream. The value of FP registers in the core dump file comes from the thread.fstate. However, kernel saves the FP registers to the thread.fstate only before scheduling out the process. If no process switch happens during the exception handling process, kernel will not have a chance to save the latest value of FP registers to thread.fstate. It will cause the value of FP registers in the core dump file may be incorrect. To solve this problem, this patch force lets kernel save the FP register into the thread.fstate if the target task_struct equals the current. Signed-off-by: Vincent Chen Reviewed-by: Jisheng Zhang Fixes: b8c8a9590e4f ("RISC-V: Add FP register ptrace support for gdb.") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

riscv: Fix a number of free'd resources in init_resources()

2021-08-26T12:35:18Z

[ Upstream commit aa3e1ba32e553e611a58145c2eb349802feaa6eb ] Function init_resources() allocates a boot memory block to hold an array of resources which it adds to iomem_resource. The array is filled in from its end and the function then attempts to free any unused memory at the beginning. The problem is that size of the unused memory is incorrectly calculated and this can result in releasing memory which is in use by active resources. Their data then gets corrupted later when the memory is reused by a different part of the system. Fix the size of the released memory to correctly match the number of unused resource entries. Fixes: ffe0e5261268 ("RISC-V: Improve init_resources()") Signed-off-by: Petr Pavlu Reviewed-by: Sunil V L Acked-by: Nick Kossifidis Tested-by: Sunil V L Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv: kexec: do not add '-mno-relax' flag if compiler doesn't support it

2021-08-18T07:06:50Z

commit 030d6dbf0c2e5fdf23ad29557f0c87a882993e26 upstream. The RISC-V special option '-mno-relax' which to disable linker relaxations is supported by GCC8+. For GCC7 and lower versions do not support this option. Fixes: fba8a8674f68 ("RISC-V: Add kexec support") Signed-off-by: Changbin Du Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

riscv: dts: fix memory size for the SiFive HiFive Unmatched

2021-08-12T11:32:26Z

commit d09560435cb712c9ec1e62b8a43a79b0af69fe77 upstream. The production version of HiFive Unmatched have 16GB memory. Signed-off-by: Qiu Wenbo Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

riscv: Disable STACKPROTECTOR_PER_TASK if GCC_PLUGIN_RANDSTRUCT is enabled

2021-08-12T11:32:10Z

[ Upstream commit a18b14d8886614b3c7d290c4cfc33389822b0535 ] riscv uses the value of TSK_STACK_CANARY to set stack-protector-guard-offset. With GCC_PLUGIN_RANDSTRUCT enabled, that value is non-deterministic, and with riscv:allmodconfig often results in build errors such as cc1: error: '8120' is not a valid offset in '-mstack-protector-guard-offset=' Enable STACKPROTECTOR_PER_TASK only if GCC_PLUGIN_RANDSTRUCT is disabled to fix the problem. Fixes: fea2fed201ee5 ("riscv: Enable per-task stack canaries") Signed-off-by: Guenter Roeck Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv: stacktrace: Fix NULL pointer dereference

2021-08-12T11:32:05Z

[ Upstream commit 78d9d8005e4556448f398d876f29d0ca7ab8e398 ] When CONFIG_FRAME_POINTER=y, calling dump_stack() can always trigger NULL pointer dereference panic similar as below: [ 0.396060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc5+ #47 [ 0.396692] Hardware name: riscv-virtio,qemu (DT) [ 0.397176] Call Trace: [ 0.398191] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000960 [ 0.399487] Oops [#1] [ 0.399739] Modules linked in: [ 0.400135] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc5+ #47 [ 0.400570] Hardware name: riscv-virtio,qemu (DT) [ 0.400926] epc : walk_stackframe+0xc4/0xdc [ 0.401291] ra : dump_backtrace+0x30/0x38 [ 0.401630] epc : ffffffff80004922 ra : ffffffff8000496a sp : ffffffe000f3bd00 [ 0.402115] gp : ffffffff80cfdcb8 tp : ffffffe000f30000 t0 : ffffffff80d0b0cf [ 0.402602] t1 : ffffffff80d0b0c0 t2 : 0000000000000000 s0 : ffffffe000f3bd60 [ 0.403071] s1 : ffffffff808bc2e8 a0 : 0000000000001000 a1 : 0000000000000000 [ 0.403448] a2 : ffffffff803d7088 a3 : ffffffff808bc2e8 a4 : 6131725dbc24d400 [ 0.403820] a5 : 0000000000001000 a6 : 0000000000000002 a7 : ffffffffffffffff [ 0.404226] s2 : 0000000000000000 s3 : 0000000000000000 s4 : 0000000000000000 [ 0.404634] s5 : ffffffff803d7088 s6 : ffffffff808bc2e8 s7 : ffffffff80630650 [ 0.405085] s8 : ffffffff80912a80 s9 : 0000000000000008 s10: ffffffff804000fc [ 0.405388] s11: 0000000000000000 t3 : 0000000000000043 t4 : ffffffffffffffff [ 0.405616] t5 : 000000000000003d t6 : ffffffe000f3baa8 [ 0.405793] status: 0000000000000100 badaddr: 0000000000000960 cause: 000000000000000d [ 0.406135] [] walk_stackframe+0xc4/0xdc [ 0.407032] [] dump_backtrace+0x30/0x38 [ 0.407797] [] show_stack+0x40/0x4c [ 0.408234] [] dump_stack+0x90/0xb6 [ 0.409019] [] ptdump_init+0x20/0xc4 [ 0.409681] [] do_one_initcall+0x4c/0x226 [ 0.410110] [] kernel_init_freeable+0x1f4/0x258 [ 0.410562] [] kernel_init+0x22/0x148 [ 0.410959] [] ret_from_exception+0x0/0x14 [ 0.412241] ---[ end trace b2ab92c901b96251 ]--- [ 0.413099] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b The reason is the task is NULL when we finally call walk_stackframe() the NULL is passed from __dump_stack(): |static void __dump_stack(void) |{ | dump_stack_print_info(KERN_DEFAULT); | show_stack(NULL, NULL, KERN_DEFAULT); |} Fix this issue by checking "task == NULL" case in walk_stackframe(). Fixes: eac2f3059e02 ("riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled") Signed-off-by: Jisheng Zhang Reviewed-by: Atish Patra Tested-by: Wende Tan Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

bpf: Introduce BPF nospec instruction for mitigating Spectre v4

2021-08-04T10:47:56Z

[ Upstream commit f5e81d1117501546b7be050c5fbafa6efd2c722c ] In case of JITs, each of the JIT backends compiles the BPF nospec instruction /either/ to a machine instruction which emits a speculation barrier /or/ to /no/ machine instruction in case the underlying architecture is not affected by Speculative Store Bypass or has different mitigations in place already. This covers both x86 and (implicitly) arm64: In case of x86, we use 'lfence' instruction for mitigation. In case of arm64, we rely on the firmware mitigation as controlled via the ssbd kernel parameter. Whenever the mitigation is enabled, it works for all of the kernel code with no need to provide any additional instructions here (hence only comment in arm64 JIT). Other archs can follow as needed. The BPF nospec instruction is specifically targeting Spectre v4 since i) we don't use a serialization barrier for the Spectre v1 case, and ii) mitigation instructions for v1 and v4 might be different on some archs. The BPF nospec is required for a future commit, where the BPF verifier does annotate intermediate BPF programs with speculation barriers. Co-developed-by: Piotr Krysiuk Co-developed-by: Benedict Schlueter Signed-off-by: Daniel Borkmann Signed-off-by: Piotr Krysiuk Signed-off-by: Benedict Schlueter Acked-by: Alexei Starovoitov Signed-off-by: Sasha Levin

RISC-V: load initrd wherever it fits into memory

2021-07-28T12:37:33Z

[ Upstream commit c79e89ecaa246c880292ba68cbe08c9c30db77e3 ] Requiring that initrd is loaded below RAM start + 256 MiB led to failure to boot SUSE Linux with GRUB on QEMU, cf. https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00037.html Remove the constraint. Reported-by: Andreas Schwab Signed-off-by: Heinrich Schuchardt Reviewed-by: Atish Patra Acked-by: Ard Biesheuvel Fixes: d7071743db31 ("RISC-V: Add EFI stub support.") Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin