linux.git/arch/riscv, branch v6.16

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

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

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 
Link: https://lore.kernel.org/r/20250715-riscv-uaccess-fix-self-init-val-v1-1-82b8e911f120@kernel.org
Signed-off-by: Palmer Dabbelt

riscv: Stop supporting static ftrace

2025-07-16T16:07:24+00:00

Now that DYNAMIC_FTRACE was introduced, there is no need to support
static ftrace as it is way less performant. This simplifies the code and
prevents build failures as reported by kernel test robot when
!DYNAMIC_FTRACE.

Also make sure that FUNCTION_TRACER can only be selected if
DYNAMIC_FTRACE is supported (we have a dependency on the toolchain).

Co-developed-by: chenmiao 
Signed-off-by: chenmiao 
Fixes: b2137c3b6d7a ("riscv: ftrace: prepare ftrace for atomic code patching")
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202506191949.o3SMu8Zn-lkp@intel.com/
Signed-off-by: Alexandre Ghiti 
Link: https://lore.kernel.org/r/20250716-dev-alex-static_ftrace-v1-1-ba5d2b6fc9c0@rivosinc.com
Signed-off-by: Palmer Dabbelt

riscv: traps_misaligned: properly sign extend value in misaligned load handler

2025-07-16T16:05:39+00:00

Add missing cast to signed long.

Signed-off-by: Andreas Schwab 
Fixes: 956d705dd279 ("riscv: Unaligned load/store handling for M_MODE")
Tested-by: Clément Léger 
Link: https://lore.kernel.org/r/mvmikk0goil.fsf@suse.de
Signed-off-by: Palmer Dabbelt

riscv: Enable interrupt during exception handling

2025-07-16T16:05:26+00:00

force_sig_fault() takes a spinlock, which is a sleeping lock with
CONFIG_PREEMPT_RT=y. However, exception handling calls force_sig_fault()
with interrupt disabled, causing a sleeping in atomic context warning.

This can be reproduced using userspace programs such as:
    int main() { asm ("ebreak"); }
or
    int main() { asm ("unimp"); }

There is no reason that interrupt must be disabled while handling
exceptions from userspace.

Enable interrupt while handling user exceptions. This also has the added
benefit of avoiding unnecessary delays in interrupt handling.

Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry")
Suggested-by: Sebastian Andrzej Siewior 
Signed-off-by: Nam Cao 
Reviewed-by: Alexandre Ghiti 
Link: https://lore.kernel.org/r/20250625085630.3649485-1-namcao@linutronix.de
Signed-off-by: Palmer Dabbelt

riscv: ftrace: Properly acquire text_mutex to fix a race condition

2025-07-16T15:21:47+00:00

As reported by lockdep, some patching was done without acquiring
text_mutex, so there could be a race when mapping the page to patch
since we use the same fixmap entry.

Reported-by: Han Gao 
Reported-by: Vivian Wang 
Reported-by: Yao Zi 
Closes: https://lore.kernel.org/linux-riscv/aGODMpq7TGINddzM@pie.lan/
Tested-by: Yao Zi 
Tested-by: Han Gao 
Reviewed-by: Masami Hiramatsu (Google) 
Signed-off-by: Alexandre Ghiti 
Link: https://lore.kernel.org/r/20250711-alex-fixes-v2-1-d85a5438da6c@rivosinc.com
Signed-off-by: Palmer Dabbelt

riscv: Stop considering R_RISCV_NONE as bad relocations

2025-07-16T15:13:55+00:00

Even though those relocations should not be present in the final
vmlinux, there are a lot of them. And since those relocations are
considered "bad", they flood the compilation output which may hide some
legitimate bad relocations.

Signed-off-by: Alexandre Ghiti 
Tested-by: Ron Economos 
Link: https://lore.kernel.org/r/20250710-dev-alex-riscv_none_bad_relocs_v1-v1-1-758f2fcc6e75@rivosinc.com
Signed-off-by: Palmer Dabbelt

RISC-V: KVM: Move HGEI[E|P] CSR access to IMSIC virtualization

2025-07-11T13:03:27+00:00

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 
Tested-by: Atish Patra 
Tested-by: Heinrich Schuchardt 
Fixes: 3385339296d1 ("RISC-V: KVM: Use IMSIC guest files when available")
Signed-off-by: Anup Patel 
Reviewed-by: Nutty Liu 
Link: https://lore.kernel.org/r/20250707035345.17494-3-apatel@ventanamicro.com
Signed-off-by: Anup Patel

RISC-V: KVM: Disable vstimecmp before exiting to user-space

2025-07-11T13:00:17+00:00

If VS-timer expires when no VCPU running on a host CPU then WFI
executed by such host CPU will be effective NOP resulting in no
power savings. This is as-per RISC-V Privileged specificaiton
which says: "WFI is also required to resume execution for locally
enabled interrupts pending at any privilege level, regardless of
the global interrupt enable at each privilege level."

To address the above issue, vstimecmp CSR must be set to -1UL over
here when VCPU is scheduled-out or exits to user space.

Reviewed-by: Atish Patra 
Tested-by: Atish Patra 
Tested-by: Heinrich Schuchardt 
Fixes: 8f5cb44b1bae ("RISC-V: KVM: Support sstc extension")
Fixes: cea8896bd936 ("RISC-V: KVM: Fix kvm_riscv_vcpu_timer_pending() for Sstc")
Reported-by: Heinrich Schuchardt 
Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2112578
Signed-off-by: Anup Patel 
Reviewed-by: Nutty Liu 
Link: https://lore.kernel.org/r/20250707035345.17494-2-apatel@ventanamicro.com
Signed-off-by: Anup Patel

riscv: cpu_ops_sbi: Use static array for boot_data

2025-06-30T06:58:11+00:00

Since commit 6b9f29b81b15 ("riscv: Enable pcpu page first chunk
allocator"), if NUMA is enabled, the page percpu allocator may be used
on very sparse configurations, or when requested on boot with
percpu_alloc=page.

In that case, percpu data gets put in the vmalloc area. However,
sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,
and simply assumes that __pa() would work. This causes the just started
hart to immediately access an invalid address and hang.

Fortunately, struct sbi_hart_boot_data is not too large, so we can
simply allocate an array for boot_data statically, putting it in the
kernel image.

This fixes NUMA=y SMP boot on Sophgo SG2042.

To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then
run with:

  qemu-system-riscv64 -M virt -smp 2 -nographic \
    -kernel arch/riscv/boot/Image \
    -append "percpu_alloc=page"

Kernel output:

[    0.000000] Booting Linux on hartid 0
[    0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025
...
[    0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712
...
[    0.083192] smp: Bringing up secondary CPUs ...
[    0.086722] ------------[ cut here ]------------
[    0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)
[    0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8
[    0.088376] Modules linked in:
[    0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE
[    0.088833] Hardware name: riscv-virtio,qemu (DT)
[    0.088948] epc : __virt_to_phys+0xae/0xe8
[    0.089001]  ra : __virt_to_phys+0xae/0xe8
[    0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0
[    0.089057]  gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976
[    0.089076]  t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0
[    0.089095]  s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000
[    0.089113]  a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
[    0.089131]  a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
[    0.089155]  s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001
[    0.089174]  s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec
[    0.089193]  s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000
[    0.089211]  s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7
[    0.089960]  t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8
[    0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003
[    0.090101] [] __virt_to_phys+0xae/0xe8
[    0.090228] [] sbi_cpu_start+0x6e/0xe8
[    0.090247] [] __cpu_up+0x1e/0x8c
[    0.090260] [] bringup_cpu+0x42/0x258
[    0.090277] [] cpuhp_invoke_callback+0xe0/0x40c
[    0.090292] [] __cpuhp_invoke_callback_range+0x68/0xfc
[    0.090320] [] _cpu_up+0x11a/0x244
[    0.090334] [] cpu_up+0x52/0x90
[    0.090384] [] bringup_nonboot_cpus+0x78/0x118
[    0.090411] [] smp_init+0x34/0xb8
[    0.090425] [] kernel_init_freeable+0x148/0x2e4
[    0.090442] [] kernel_init+0x1e/0x14c
[    0.090455] [] ret_from_fork_kernel+0xe/0xf0
[    0.090471] [] ret_from_fork_kernel_asm+0x16/0x18
[    0.090560] ---[ end trace 0000000000000000 ]---
[    1.179875] CPU1: failed to come online
[    1.190324] smp: Brought up 1 node, 1 CPU

Cc: stable@vger.kernel.org
Reported-by: Han Gao 
Fixes: 6b9f29b81b15 ("riscv: Enable pcpu page first chunk allocator")
Reviewed-by: Alexandre Ghiti 
Tested-by: Alexandre Ghiti 
Signed-off-by: Vivian Wang 
Link: https://lore.kernel.org/r/20250624-riscv-hsm-boot-data-array-v1-1-50b5eeafbe61@iscas.ac.cn
Signed-off-by: Alexandre Ghiti