Alex fixes manual#470
Closed
AlexGhiti wants to merge 10 commits into
Closed
Conversation
AlexGhiti
force-pushed
the
alex-fixes_manual
branch
4 times, most recently
from
c1a1a24 to
03442ee
Compare
.rodata is implicitly included in the PT_DYNAMIC segment due to inheriting the segment of the preceding .dynamic section (in both GNU ld and LLD). When the .rodata section's size is not a multiple of 16 bytes on riscv64, llvm-readelf will report a "PT_DYNAMIC dynamic table is invalid" warning. Note: in the presence of the .dynamic section, GNU readelf and llvm-readelf's -d option decodes the dynamic section using the section. This issue arose after commit 8f8c1ff ("riscv: vdso.lds.S: remove hardcoded 0x800 .text start addr"), which placed .rodata directly after .dynamic by removing .eh_frame. This patch resolves the implicit inclusion into PT_DYNAMIC by explicitly specifying the :text output section phdr. Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: ClangBuiltLinux#2093 Signed-off-by: Fangrui Song <i@maskray.me> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250602-riscv-vdso-v1-1-0620cf63cff0@maskray.me Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
the `__runtime_fixup_32` function does not handle the case where `val` is zero correctly (as might occur when patching a nommu kernel and referring to a physical address below the 4GiB boundary whose upper 32 bits are all zero) because nothing in the existing logic prevents the code from taking the `else` branch of both nop-checks and emitting two `nop` instructions. This leaves random garbage in the register that is supposed to receive the upper 32 bits of the pointer instead of zero that when combined with the value for the lower 32 bits yields an invalid pointer and causes a kernel panic when that pointer is eventually accessed. The author clearly considered the fact that if the `lui` is converted into a `nop` that the second instruction needs to be adjusted to become an `li` instead of an `addi`, hence introducing the `addi_insn_mask` variable, but didn't follow that logic through fully to the case where the `else` branch executes. To fix it just adjust the logic to ensure that the second `else` branch is not taken if the first instruction will be patched to a `nop`. Fixes: a44fb57 ("riscv: Add runtime constant support") Signed-off-by: Charles Mirabile <cmirabil@redhat.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20250530211422.784415-2-cmirabil@redhat.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
Previously only v0-v7 were correctly saved/restored, and the context of v8-v31 are damanged. Correctly save/restore v8-v31 to avoid breaking userspace. Fixes: d863910 ("riscv: vector: Support xtheadvector save/restore") Cc: stable@vger.kernel.org Signed-off-by: Han Gao <rabenda.cn@gmail.com> Tested-by: Xiongchuan Tan <tanxiongchuan@isrc.iscas.ac.cn> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Reviewed-by: Andy Chiu <andybnac@gmail.com> Link: https://lore.kernel.org/r/9b9eb2337f3d5336ce813721f8ebea51e0b2b553.1747994822.git.rabenda.cn@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
…scall wrapper As recently pointed out by Thomas, if a register is forced for two different register variables, among them one is used as "+" (both input and output) and another is only used as input, Clang would treat the conflicting input parameters as undefined behaviour and optimize away the argument assignment. Instead use "=r" (only output) for the output parameter and "r" (only input) for the input parameter. While the example from the GCC documentation uses "0" for the input parameter, this is not necessary as confirmed by the GCC developers and "r" matches what the other architectures' vDSO implementations are using. [ alex: Update log to match v2 (Thomas) ] Link: https://lore.kernel.org/all/20250603-loongarch-vdso-syscall-v1-1-6d12d6dfbdd0@linutronix.de/ Link: https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Local-Register-Variables.html Link: https://gcc.gnu.org/pipermail/gcc-help/2025-June/144266.html Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Xi Ruoyao <xry111@xry111.site> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Fixes: ee0d030 ("RISC-V: vDSO: Wire up getrandom() vDSO") Link: https://lore.kernel.org/r/20250606092443.73650-2-xry111@xry111.site Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
…/linux/kernel/git/alexghiti/linux into fixes riscv fixes for 6.16-rc1 - A fix for the newly introduced getrandom vdso where clang optimizes away a register variable which is both an input and an output parameter - A fix for theadvector where we did not save all the vector registers, only a few of them * tag 'riscv-fixes-6.16-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux: RISC-V: vDSO: Correct inline assembly constraints in the getrandom syscall wrapper riscv: vector: Fix context save/restore with xtheadvector
When running the raid6 user-space test program on RISC-V QEMU, there's a segmentation fault which seems caused by accessing a NULL pointer, which is the pointer variable p/q in raid6_rvv*_gen/xor_syndrome_real(), p/q should have been equal to dptr[x], but when I use GDB command to see its value, which was 0x10 like below: " Program received signal SIGSEGV, Segmentation fault. 0x0000000000011062 in raid6_rvv2_xor_syndrome_real (disks=<optimized out>, start=0, stop=<optimized out>, bytes=4096, ptrs=<optimized out>) at rvv.c:386 (gdb) p p $1 = (u8 *) 0x10 <error: Cannot access memory at address 0x10> " The issue was found to be related with: 1) Compile optimization There's no segmentation fault if compiling the raid6test program with the optimization flag -O0. 2) The RISC-V vector command vsetvli If not used t0 as the first parameter in vsetvli, there's no segmentation fault either. This patch selects the 2nd solution to fix the issue. [Palmer: The actual issue here is a missing clobber in the vsetvli code. It's a little tricky: we've already probed for VLENB so we don't need to look at the output register, we just need to have an X register in the instruction as that's the form required to actually set VL. Thus we clobber a register, and without describing that we end up breaking compilers.] Fixes: 6093faa ("raid6: Add RISC-V SIMD syndrome and recovery calculations") Signed-off-by: Chunyan Zhang <zhangchunyan@iscas.ac.cn> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250610101234.1100660-3-zhangchunyan@iscas.ac.cn Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
…upport" This is a fix in the middle of a feature set, so I'm going to take the fix onto fixes on its own. * b4-shazam-merge: raid6: riscv: Fix NULL pointer dereference issue Link: https://lore.kernel.org/r/20250610101234.1100660-1-zhangchunyan@iscas.ac.cn Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
I must have lost this rebasing things during the merge window, I know I
got it at some point but it's not here now. Without this I get warnings
along the lines of
include/linux/fs.h:3975:15: warning: label followed by a declaration is a C23 extension [-Wc23-extensions]
3975 | if (unlikely(get_user(c, path)))
| ^
arch/riscv/include/asm/uaccess.h:274:3: note: expanded from macro 'get_user'
274 | __get_user((x), __p) : \
| ^
arch/riscv/include/asm/uaccess.h:244:2: note: expanded from macro '__get_user'
244 | __get_user_error(__gu_val, __gu_ptr, __gu_err); \
| ^
arch/riscv/include/asm/uaccess.h:207:2: note: expanded from macro '__get_user_error'
207 | __ge LD [M] net/802/psnap.ko
t_user_nocheck(x, ptr, __gu_failed); \
| ^
arch/riscv/include/asm/uaccess.h:196:3: note: expanded from macro '__get_user_nocheck'
196 | __get_user_8((x), __gu_ptr, label); \
| ^
arch/riscv/include/asm/uaccess.h:130:2: note: expanded from macro '__get_user_8'
130 | u32 __user *__ptr = (u32 __user *)(ptr); \
| ^
Link: https://lore.kernel.org/r/20250610213058.24852-1-palmer@dabbelt.com
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Cc: stable@vger.kernel.org
Fixes: f6bff78 ("riscv: uaccess: use 'asm_goto_output' for get_user()")
Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
After the combination of commit c217157 ("riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS"), which starts using '-fpatchable-function-entry=M,N', and commit d0262e9 ("riscv: ftrace: support PREEMPT"), which allows CONFIG_DYNAMIC_FTRACE to be enabled by allmodconfig, allmodconfig builds with clang-16 begin crashing in the generic LLVM kCFI pass (see [1] for the stack trace). clang-17 avoids this crash by moving to target-specific lowering of the kCFI operand bundles [2]. Require clang-17 to select CONFIG_CFI_CLANG to avoid this crash. Fixes: c217157 ("riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS") Link: https://godbolt.org/z/xG39Pn16o [1] Link: llvm/llvm-project@62fa708 [2] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20250612-riscv-require-clang-17-for-kcfi-v1-1-216f7cd7d87f@kernel.org Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
AlexGhiti
force-pushed
the
alex-fixes_manual
branch
from
03442ee to
ceeaea1
Compare
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
AlexGhiti
force-pushed
the
alex-fixes_manual
branch
from
ceeaea1 to
8c5aac6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.