linux.git/arch/riscv/include, branch v6.16 Linux kernel source tree Merge tag 'riscv-for-linus-6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux 2025-07-18T22:31:46+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-07-18T22:31:46+00:00 414aaef1537ac7f90dcb54e618864680aca2e197 Pull RISC-V fixes from Palmer Dabbelt: - Three fixes for unnecessary spew: an ACPI CPPC boot-time debug message, the link-time warnings for R_RISCV_NONE in binaries, and some compile-time warnings in __put_user_nocheck - A fix for a race during text patching - Interrupts are no longer disabled during exception handling - A fix for a missing sign extension in the misaligned load handler - A fix to avoid static ftrace being selected in Kconfig, as we have moved to dynamic ftrace * tag 'riscv-for-linus-6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: uaccess: Fix -Wuninitialized and -Wshadow in __put_user_nocheck riscv: Stop supporting static ftrace riscv: traps_misaligned: properly sign extend value in misaligned load handler riscv: Enable interrupt during exception handling riscv: ftrace: Properly acquire text_mutex to fix a race condition ACPI: RISC-V: Remove unnecessary CPPC debug message riscv: Stop considering R_RISCV_NONE as bad relocations 
Pull RISC-V fixes from Palmer Dabbelt:

 - Three fixes for unnecessary spew: an ACPI CPPC boot-time debug
   message, the link-time warnings for R_RISCV_NONE in binaries, and
   some compile-time warnings in __put_user_nocheck

 - A fix for a race during text patching

 - Interrupts are no longer disabled during exception handling

 - A fix for a missing sign extension in the misaligned load handler

 - A fix to avoid static ftrace being selected in Kconfig, as we have
   moved to dynamic ftrace

* tag 'riscv-for-linus-6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: uaccess: Fix -Wuninitialized and -Wshadow in __put_user_nocheck
  riscv: Stop supporting static ftrace
  riscv: traps_misaligned: properly sign extend value in misaligned load handler
  riscv: Enable interrupt during exception handling
  riscv: ftrace: Properly acquire text_mutex to fix a race condition
  ACPI: RISC-V: Remove unnecessary CPPC debug message
  riscv: Stop considering R_RISCV_NONE as bad relocations
riscv: uaccess: Fix -Wuninitialized and -Wshadow in __put_user_nocheck 2025-07-16T17:29:39+00:00 Nathan Chancellor nathan@kernel.org 2025-07-16T03:07:01+00:00 b65ca21835ed615907ba231a60db80a2605b94dc After a recent change in clang to strengthen uninitialized warnings [1], there is a warning from val being uninitialized in __put_user_nocheck when called from futex_put_value(): kernel/futex/futex.h:326:18: warning: variable 'val' is uninitialized when used within its own initialization [-Wuninitialized] 326 | unsafe_put_user(val, to, Efault); | ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ arch/riscv/include/asm/uaccess.h:464:21: note: expanded from macro 'unsafe_put_user' 464 | __put_user_nocheck(x, (ptr), label) | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ arch/riscv/include/asm/uaccess.h:314:36: note: expanded from macro '__put_user_nocheck' 314 | __inttype(x) val = (__inttype(x))x; \ | ~~~ ^ While not on by default, -Wshadow flags the same mistake: kernel/futex/futex.h:326:2: warning: declaration shadows a local variable [-Wshadow] 326 | unsafe_put_user(val, to, Efault); | ^ arch/riscv/include/asm/uaccess.h:464:2: note: expanded from macro 'unsafe_put_user' 464 | __put_user_nocheck(x, (ptr), label) | ^ arch/riscv/include/asm/uaccess.h:314:16: note: expanded from macro '__put_user_nocheck' 314 | __inttype(x) val = (__inttype(x))x; \ | ^ kernel/futex/futex.h:320:48: note: previous declaration is here 320 | static __always_inline int futex_put_value(u32 val, u32 __user *to) | ^ Use a three underscore prefix for the val variable in __put_user_nocheck to avoid clashing with either val or __val, which are both used within the put_user macros, clearing up all warnings. Closes: https://github.com/ClangBuiltLinux/linux/issues/2109 Fixes: ca1a66cdd685 ("riscv: uaccess: do not do misaligned accesses in get/put_user()") Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cdee01472c7 [1] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250715-riscv-uaccess-fix-self-init-val-v1-1-82b8e911f120@kernel.org Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com> 
After a recent change in clang to strengthen uninitialized warnings [1],
there is a warning from val being uninitialized in __put_user_nocheck
when called from futex_put_value():

  kernel/futex/futex.h:326:18: warning: variable 'val' is uninitialized when used within its own initialization [-Wuninitialized]
    326 |         unsafe_put_user(val, to, Efault);
        |         ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
  arch/riscv/include/asm/uaccess.h:464:21: note: expanded from macro 'unsafe_put_user'
    464 |         __put_user_nocheck(x, (ptr), label)
        |         ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
  arch/riscv/include/asm/uaccess.h:314:36: note: expanded from macro '__put_user_nocheck'
    314 |                 __inttype(x) val = (__inttype(x))x;                     \
        |                              ~~~                 ^

While not on by default, -Wshadow flags the same mistake:

  kernel/futex/futex.h:326:2: warning: declaration shadows a local variable [-Wshadow]
    326 |         unsafe_put_user(val, to, Efault);
        |         ^
  arch/riscv/include/asm/uaccess.h:464:2: note: expanded from macro 'unsafe_put_user'
    464 |         __put_user_nocheck(x, (ptr), label)
        |         ^
  arch/riscv/include/asm/uaccess.h:314:16: note: expanded from macro '__put_user_nocheck'
    314 |                 __inttype(x) val = (__inttype(x))x;                     \
        |                              ^
  kernel/futex/futex.h:320:48: note: previous declaration is here
    320 | static __always_inline int futex_put_value(u32 val, u32 __user *to)
        |                                                ^

Use a three underscore prefix for the val variable in __put_user_nocheck
to avoid clashing with either val or __val, which are both used within
the put_user macros, clearing up all warnings.

Closes: https://github.com/ClangBuiltLinux/linux/issues/2109
Fixes: ca1a66cdd685 ("riscv: uaccess: do not do misaligned accesses in get/put_user()")
Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cdee01472c7 [1]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20250715-riscv-uaccess-fix-self-init-val-v1-1-82b8e911f120@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
RISC-V: KVM: Move HGEI[E|P] CSR access to IMSIC virtualization 2025-07-11T13:03:27+00:00 Anup Patel apatel@ventanamicro.com 2025-07-07T03:53:44+00:00 4cec89db80ba81fa4524c6449c0494b8ae08eeb0 Currently, the common AIA functions kvm_riscv_vcpu_aia_has_interrupts() and kvm_riscv_aia_wakeon_hgei() lookup HGEI line using an array of VCPU pointers before accessing HGEI[E|P] CSR which is slow and prone to race conditions because there is a separate per-hart lock for the VCPU pointer array and a separate per-VCPU rwlock for IMSIC VS-file (including HGEI line) used by the VCPU. Due to these race conditions, it is observed on QEMU RISC-V host that Guest VCPUs sleep in WFI and never wakeup even with interrupt pending in the IMSIC VS-file because VCPUs were waiting for HGEI wakeup on the wrong host CPU. The IMSIC virtualization already keeps track of the HGEI line and the associated IMSIC VS-file used by each VCPU so move the HGEI[E|P] CSR access to IMSIC virtualization so that costly HGEI line lookup can be avoided and likelihood of race-conditions when updating HGEI[E|P] CSR is also reduced. Reviewed-by: Atish Patra <atishp@rivosinc.com> Tested-by: Atish Patra <atishp@rivosinc.com> Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Fixes: 3385339296d1 ("RISC-V: KVM: Use IMSIC guest files when available") Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Link: https://lore.kernel.org/r/20250707035345.17494-3-apatel@ventanamicro.com Signed-off-by: Anup Patel <anup@brainfault.org> 
Currently, the common AIA functions kvm_riscv_vcpu_aia_has_interrupts()
and kvm_riscv_aia_wakeon_hgei() lookup HGEI line using an array of VCPU
pointers before accessing HGEI[E|P] CSR which is slow and prone to race
conditions because there is a separate per-hart lock for the VCPU pointer
array and a separate per-VCPU rwlock for IMSIC VS-file (including HGEI
line) used by the VCPU. Due to these race conditions, it is observed
on QEMU RISC-V host that Guest VCPUs sleep in WFI and never wakeup even
with interrupt pending in the IMSIC VS-file because VCPUs were waiting
for HGEI wakeup on the wrong host CPU.

The IMSIC virtualization already keeps track of the HGEI line and the
associated IMSIC VS-file used by each VCPU so move the HGEI[E|P] CSR
access to IMSIC virtualization so that costly HGEI line lookup can be
avoided and likelihood of race-conditions when updating HGEI[E|P] CSR
is also reduced.

Reviewed-by: Atish Patra <atishp@rivosinc.com>
Tested-by: Atish Patra <atishp@rivosinc.com>
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: 3385339296d1 ("RISC-V: KVM: Use IMSIC guest files when available")
Signed-off-by: Anup Patel <apatel@ventanamicro.com>
Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com>
Link: https://lore.kernel.org/r/20250707035345.17494-3-apatel@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org>
Merge tag 'riscv-for-linus-5.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux 2025-06-28T03:22:18+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-06-28T03:22:18+00:00 867b9987a30b7f68a6e9e89d3670730692222a4a Pull RISC-V Fixes for 5.16-rc4 - .rodata is no longer linkd into PT_DYNAMIC. It was not supposed to be there in the first place and resulted in invalid (but unused) entries. This manifests as at least warnings in llvm-readelf - A fix for runtime constants with all-0 upper 32-bits. This should only manifest on MMU=n kernels - A fix for context save/restore on systems using the T-Head vector extensions - A fix for a conflicting "+r"/"r" register constraint in the VDSO getrandom syscall wrapper, which is undefined behavior in clang - A fix for a missing register clobber in the RVV raid6 implementation. This manifests as a NULL pointer reference on some compilers, but could trigger in other ways - Misaligned accesses from userspace at faulting addresses are now handled correctly - A fix for an incorrect optimization that allowed access_ok() to mark invalid addresses as accessible, which can result in userspace triggering BUG()s - A few fixes for build warnings, and an update to Drew's email address * tag 'riscv-for-linus-5.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: export boot_cpu_hartid Revert "riscv: Define TASK_SIZE_MAX for __access_ok()" riscv: Fix sparse warning in vendor_extensions/sifive.c Revert "riscv: misaligned: fix sleeping function called during misaligned access handling" MAINTAINERS: Update Drew Fustini's email address RISC-V: uaccess: Wrap the get_user_8 uaccess macro raid6: riscv: Fix NULL pointer dereference caused by a missing clobber RISC-V: vDSO: Correct inline assembly constraints in the getrandom syscall wrapper riscv: vector: Fix context save/restore with xtheadvector riscv: fix runtime constant support for nommu kernels riscv: vdso: Exclude .rodata from the PT_DYNAMIC segment 
Pull RISC-V Fixes for 5.16-rc4

 - .rodata is no longer linkd into PT_DYNAMIC.

   It was not supposed to be there in the first place and resulted in
   invalid (but unused) entries. This manifests as at least warnings in
   llvm-readelf

 - A fix for runtime constants with all-0 upper 32-bits. This should
   only manifest on MMU=n kernels

 - A fix for context save/restore on systems using the T-Head vector
   extensions

 - A fix for a conflicting "+r"/"r" register constraint in the VDSO
   getrandom syscall wrapper, which is undefined behavior in clang

 - A fix for a missing register clobber in the RVV raid6 implementation.

   This manifests as a NULL pointer reference on some compilers, but
   could trigger in other ways

 - Misaligned accesses from userspace at faulting addresses are now
   handled correctly

 - A fix for an incorrect optimization that allowed access_ok() to mark
   invalid addresses as accessible, which can result in userspace
   triggering BUG()s

 - A few fixes for build warnings, and an update to Drew's email address

* tag 'riscv-for-linus-5.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: export boot_cpu_hartid
  Revert "riscv: Define TASK_SIZE_MAX for __access_ok()"
  riscv: Fix sparse warning in vendor_extensions/sifive.c
  Revert "riscv: misaligned: fix sleeping function called during misaligned access handling"
  MAINTAINERS: Update Drew Fustini's email address
  RISC-V: uaccess: Wrap the get_user_8 uaccess macro
  raid6: riscv: Fix NULL pointer dereference caused by a missing clobber
  RISC-V: vDSO: Correct inline assembly constraints in the getrandom syscall wrapper
  riscv: vector: Fix context save/restore with xtheadvector
  riscv: fix runtime constant support for nommu kernels
  riscv: vdso: Exclude .rodata from the PT_DYNAMIC segment
Revert "riscv: Define TASK_SIZE_MAX for __access_ok()" 2025-06-23T23:00:23+00:00 Nam Cao namcao@linutronix.de 2025-06-19T15:58:58+00:00 890ba5be6335dbbbc99af14ea007befb5f83f174 This reverts commit ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for __access_ok()"). This commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(), because the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some computation. The reasoning was that all user addresses are less than LONG_MAX, and all kernel addresses are greater than LONG_MAX. Therefore access_ok() can filter kernel addresses. Addresses between TASK_SIZE and LONG_MAX are not valid user addresses, but access_ok() let them pass. That was thought to be okay, because they are not valid addresses at hardware level. Unfortunately, one case is missed: get_user_pages_fast() happily accepts addresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses get_user_pages_fast(). This causes the problem reported by Robert [1]. Therefore, revert this commit. TASK_SIZE_MAX is changed to the default: TASK_SIZE. This unfortunately reduces performance, because TASK_SIZE is more expensive to compute compared to LONG_MAX. But correctness first, we can think about optimization later, if required. Reported-by: <rtm@csail.mit.edu> Closes: https://lore.kernel.org/linux-riscv/77605.1750245028@localhost/ Signed-off-by: Nam Cao <namcao@linutronix.de> Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Fixes: ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for __access_ok()") Link: https://lore.kernel.org/r/20250619155858.1249789-1-namcao@linutronix.de Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com> 
This reverts commit ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for
__access_ok()").

This commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(),
because the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some
computation.

The reasoning was that all user addresses are less than LONG_MAX, and all
kernel addresses are greater than LONG_MAX. Therefore access_ok() can
filter kernel addresses.

Addresses between TASK_SIZE and LONG_MAX are not valid user addresses, but
access_ok() let them pass. That was thought to be okay, because they are
not valid addresses at hardware level.

Unfortunately, one case is missed: get_user_pages_fast() happily accepts
addresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses
get_user_pages_fast(). This causes the problem reported by Robert [1].

Therefore, revert this commit. TASK_SIZE_MAX is changed to the default:
TASK_SIZE.

This unfortunately reduces performance, because TASK_SIZE is more expensive
to compute compared to LONG_MAX. But correctness first, we can think about
optimization later, if required.

Reported-by: <rtm@csail.mit.edu>
Closes: https://lore.kernel.org/linux-riscv/77605.1750245028@localhost/
Signed-off-by: Nam Cao <namcao@linutronix.de>
Cc: stable@vger.kernel.org
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Fixes: ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for __access_ok()")
Link: https://lore.kernel.org/r/20250619155858.1249789-1-namcao@linutronix.de
Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
RISC-V: uaccess: Wrap the get_user_8 uaccess macro 2025-06-12T19:41:46+00:00 Palmer Dabbelt palmer@dabbelt.com 2025-06-10T21:30:58+00:00 2aa5801ada29948ce510fc8b1e3b3ec8162423e2 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: f6bff7827a48 ("riscv: uaccess: use 'asm_goto_output' for get_user()") 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: f6bff7827a48 ("riscv: uaccess: use 'asm_goto_output' for get_user()")
Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
Merge tag 'riscv-fixes-6.16-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux into fixes 2025-06-12T19:14:06+00:00 Palmer Dabbelt palmer@dabbelt.com 2025-06-12T18:59:05+00:00 5c5ecd1f3413cce5474a16255f4212680d3ca5d5 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 
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
RISC-V: vDSO: Correct inline assembly constraints in the getrandom syscall wrapper 2025-06-12T19:13:57+00:00 Xi Ruoyao xry111@xry111.site 2025-06-06T09:24:44+00:00 2b9518684f8558cd61a7c608cc03a27822cf7b03 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: ee0d03053e70 ("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> 
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: ee0d03053e70 ("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>
riscv: vector: Fix context save/restore with xtheadvector 2025-06-12T19:13:47+00:00 Han Gao rabenda.cn@gmail.com 2025-05-23T10:25:56+00:00 4262bd0d9cc704ea1365ac00afc1272400c2cbef 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: d863910eabaf ("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> 
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: d863910eabaf ("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>
mm: pgtable: fix pte_swp_exclusive 2025-06-11T21:52:08+00:00 Magnus Lindholm linmag7@gmail.com 2025-02-18T17:55:14+00:00 403d1338a4a59cfebb4ded53fa35fbd5119f36b1 Make pte_swp_exclusive return bool instead of int. This will better reflect how pte_swp_exclusive is actually used in the code. This fixes swap/swapoff problems on Alpha due pte_swp_exclusive not returning correct values when _PAGE_SWP_EXCLUSIVE bit resides in upper 32-bits of PTE (like on alpha). Suggested-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Magnus Lindholm <linmag7@gmail.com> Cc: Sam James <sam@gentoo.org> Link: https://lore.kernel.org/lkml/20250218175735.19882-2-linmag7@gmail.com/ Link: https://lore.kernel.org/lkml/20250602041118.GA2675383@ZenIV/ [ Applied as the 'sed' script Al suggested - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Make pte_swp_exclusive return bool instead of int.  This will better
reflect how pte_swp_exclusive is actually used in the code.

This fixes swap/swapoff problems on Alpha due pte_swp_exclusive not
returning correct values when _PAGE_SWP_EXCLUSIVE bit resides in upper
32-bits of PTE (like on alpha).

Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
Cc: Sam James <sam@gentoo.org>
Link: https://lore.kernel.org/lkml/20250218175735.19882-2-linmag7@gmail.com/
Link: https://lore.kernel.org/lkml/20250602041118.GA2675383@ZenIV/
[ Applied as the 'sed' script Al suggested   - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>