kernel/git/stable/linux-stable.git/arch/riscv, branch linux-5.14.y

Revert "sched: Add wrapper for get_wchan() to keep task blocked"

2021-11-18T13:01:34+00:00

This reverts commit e9ede14c116f1a6246eee89d320d60a90a86b5d5 which is commit 42a20f86dc19f9282d974df0ba4d226c865ab9dd upstream. It has been reported to be causing problems, and is being reworked upstream and has been dropped from the current 5.15.y stable queue until it gets resolved. Reported-by: Chris Rankin Reported-by: Thorsten Leemhuis Link: https://lore.kernel.org/r/ed000478-2a60-0066-c337-a04bffc112b1@leemhuis.info Cc: Stephen Rothwell Cc: Peter Zijlstra (Intel) Cc: Kees Cook Cc: Geert Uytterhoeven Cc: Russell King (Oracle) Cc: Mark Rutland Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman

sched: Add wrapper for get_wchan() to keep task blocked

2021-11-17T10:04:16+00:00

[ Upstream commit 42a20f86dc19f9282d974df0ba4d226c865ab9dd ] Having a stable wchan means the process must be blocked and for it to stay that way while performing stack unwinding. Suggested-by: Peter Zijlstra Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Acked-by: Geert Uytterhoeven Acked-by: Russell King (Oracle) [arm] Tested-by: Mark Rutland [arm64] Link: https://lkml.kernel.org/r/20211008111626.332092234@infradead.org Signed-off-by: Sasha Levin

bpf: Define bpf_jit_alloc_exec_limit for riscv JIT

2021-11-17T10:03:30+00:00

[ Upstream commit 8f04db78e4e36a5d4858ce841a3e9cc3d69bde36 ] Expose the maximum amount of useable memory from the riscv JIT. Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Acked-by: Luke Nelson Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20211014142554.53120-2-lmb@cloudflare.com Signed-off-by: Sasha Levin

riscv: Fix asan-stack clang build

2021-11-02T18:51:02+00:00

commit 54c5639d8f507ebefa814f574cb6f763033a72a5 upstream. Nathan reported that because KASAN_SHADOW_OFFSET was not defined in Kconfig, it prevents asan-stack from getting disabled with clang even when CONFIG_KASAN_STACK is disabled: fix this by defining the corresponding config. Reported-by: Nathan Chancellor Signed-off-by: Alexandre Ghiti Fixes: 8ad8b72721d0 ("riscv: Add KASAN support") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

riscv: Do not re-populate shadow memory with kasan_populate_early_shadow

2021-11-02T18:51:02+00:00

commit cf11d01135ea1ff7fddb612033e3cb5cde279ff2 upstream. When calling this function, all the shadow memory is already populated with kasan_early_shadow_pte which has PAGE_KERNEL protection. kasan_populate_early_shadow write-protects the mapping of the range of addresses passed in argument in zero_pte_populate, which actually write-protects all the shadow memory mapping since kasan_early_shadow_pte is used for all the shadow memory at this point. And then when using memblock API to populate the shadow memory, the first write access to the kernel stack triggers a trap. This becomes visible with the next commit that contains a fix for asan-stack. We already manually populate all the shadow memory in kasan_early_init and we write-protect kasan_early_shadow_pte at the end of kasan_init which makes the calls to kasan_populate_early_shadow superfluous so we can remove them. Signed-off-by: Alexandre Ghiti Fixes: e178d670f251 ("riscv/kasan: add KASAN_VMALLOC support") Fixes: 8ad8b72721d0 ("riscv: Add KASAN support") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

riscv: fix misalgned trap vector base address

2021-11-02T18:51:01+00:00

commit 64a19591a2938b170aa736443d5d3bf4c51e1388 upstream. The trap vector marked by label .Lsecondary_park must align on a 4-byte boundary, as the {m,s}tvec is defined to require 4-byte alignment. Signed-off-by: Chen Lu <181250012@smail.nju.edu.cn> Reviewed-by: Anup Patel Fixes: e011995e826f ("RISC-V: Move relocate and few other functions out of __init") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

riscv, bpf: Fix potential NULL dereference

2021-11-02T18:50:56+00:00

commit 27de809a3d83a6199664479ebb19712533d6fd9b upstream. The bpf_jit_binary_free() function requires a non-NULL argument. When the RISC-V BPF JIT fails to converge in NR_JIT_ITERATIONS steps, jit_data->header will be NULL, which triggers a NULL dereference. Avoid this by checking the argument, prior calling the function. Fixes: ca6cb5447cec ("riscv, bpf: Factor common RISC-V JIT code") Signed-off-by: Björn Töpel Acked-by: Daniel Borkmann Link: https://lore.kernel.org/r/20211028125115.514587-1-bjorn@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

RISC-V: Include clone3() on rv32

2021-10-13T07:42:02+00:00

[ Upstream commit 59a4e0d5511ba61353ea9a4efdb1b86c23ecf134 ] As far as I can tell this should be enabled on rv32 as well, I'm not sure why it's rv64-only. checksyscalls is complaining about our lack of clone3() on rv32. Fixes: 56ac5e213933 ("riscv: enable sys_clone3 syscall for rv64") Signed-off-by: Palmer Dabbelt Reviewed-by: Arnd Bergmann Acked-by: Christian Brauner Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv/vdso: make arch_setup_additional_pages wait for mmap_sem for write killable

2021-10-13T07:42:01+00:00

[ Upstream commit 8bb0ab3ae7a4dbe6cf32deb830cf2bdbf5736867 ] riscv architectures relying on mmap_sem for write in their arch_setup_additional_pages. If the waiting task gets killed by the oom killer it would block oom_reaper from asynchronous address space reclaim and reduce the chances of timely OOM resolving. Wait for the lock in the killable mode and return with EINTR if the task got killed while waiting. Signed-off-by: Tong Tiangen Reviewed-by: Kefeng Wang Fixes: 76d2a0493a17 ("RISC-V: Init and Halt Code") Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv/vdso: Move vdso data page up front

2021-10-13T07:42:01+00:00

[ Upstream commit 78a743cd82a35ca0724179fc22834f06a2151fc2 ] As commit 601255ae3c98 ("arm64: vdso: move data page before code pages"), the same issue exists on riscv, testcase is shown below, make sure that vdso.so is bigger than page size, struct timespec tp; clock_gettime(5, &tp); printf("tv_sec: %ld, tv_nsec: %ld\n", tp.tv_sec, tp.tv_nsec); without this patch, test result : tv_sec: 0, tv_nsec: 0 with this patch, test result : tv_sec: 1629271537, tv_nsec: 748000000 Move the vdso data page in front of the VDSO area to fix the issue. Fixes: ad5d1122b82fb ("riscv: use vDSO common flow to reduce the latency of the time-related functions") Signed-off-by: Tong Tiangen Reviewed-by: Kefeng Wang Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin