linux-next.git/arch/riscv/kernel, branch master

Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

2026-09-04T17:51:04+00:00

Merge branch 'kexec-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git

2026-09-04T16:46:39+00:00

sched: Convert paravirt_steal to new static key APIs

2026-09-02T08:28:24+00:00

paravirt_steal_rq_enabled and paravirt_steal_enabled use raw static_key APIs which are now deprecated. Use the new API instead. No functional change. Signed-off-by: Hongyan Xia Signed-off-by: Peter Zijlstra (Intel) Acked-by: Juergen Gross Link: https://patch.msgid.link/20260819081207.12150-1-hongyan.xia@transsion.com

Merge patch series "kexec: fix probe error codes and error propagation"

2026-09-02T04:41:29+00:00

Mukesh Pilaniya says: kexec: fix probe error codes and error propagation While debugging a misleading error on s390x where kexec -s reported "syscall kexec_file_load not available" instead of the actual EINVAL from a kernel command line that exceeded the architecture limit, it was found that some kexec image probe functions return -EINVAL instead of -ENOEXEC for format mismatches, and kexec_image_probe_default() has a bug where it returns whatever the last loader returned rather than always returning -ENOEXEC when no loader matches. * Fix all probe functions to return -ENOEXEC when they do not recognize the image format. * Fix kexec_image_probe_default() to distinguish format mismatches (-ENOEXEC) from real errors (e.g. -ENOMEM), propagating real errors immediately and only continuing to the next loader on -ENOEXEC. kexec-tools patch: https://lore.kernel.org/all/20260814075329.30203-1-mpilaniy@redhat.com/ Link: https://patch.msgid.link/20260821-mpilaniy-v3-0-76b355399d2e@redhat.com Signed-off-by: Mike Rapoport (Microsoft)

kexec: return -ENOEXEC from image probe functions on mismatch

2026-09-02T04:41:28+00:00

Several kexec_file_load() image probe functions return -EINVAL when they do not recognize the image format. A probe function that rejects an image should return -ENOEXEC to indicate that the image is not a recognized executable format. -EINVAL implies a problem with the syscall parameters, not with image recognition. kexec_image_probe_default() iterates through registered loaders and returns the last probe's error code to the caller. That error propagates as the kexec_file_load() return value to userspace. Returning -EINVAL from a probe when no loader matches is semantically incorrect and misleads userspace about the nature of the failure. Return -ENOEXEC from all probe functions and their helpers when the image format is not recognized. Signed-off-by: Mukesh Pilaniya Reviewed-by: Philipp Rudo Reviewed-by: Pratyush Yadav Reviewed-by: Bradley Morgan Link: https://patch.msgid.link/20260821-mpilaniy-v3-1-76b355399d2e@redhat.com Signed-off-by: Mike Rapoport (Microsoft)

riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present

2026-09-02T01:19:44+00:00

The RISC-V ISA manual specifies that Zfh implies Zfhmin, a normative rule clarified in https://github.com/riscv/riscv-isa-manual/pull/3070. Zvfh likewise implies Zvfhmin, as stated by the vector extension specification. The kernel currently reports ZFH and ZFHMIN (and ZVFH and ZVFHMIN) as independent hwprobe bits derived only from what the device tree declares. Platforms that declare just "zfh" (Zfh being a superset that already contains all Zfhmin instructions) therefore report RISCV_HWPROBE_EXT_ZFHMIN=0, which breaks userspace RVA23 conformance checks (e.g. snapd installing core26 on riscv64). Use the existing superset mechanism to set the implied subset bits: - zfh implies zfhmin - zvfh implies zvfhmin Add a hwprobe selftest asserting the implication holds and update the hwprobe documentation accordingly. This is complementary to the rva23u64 base behavior discussion: the RVA23 conformance query proposed there is derived from the per-extension bits fixed here, so correct EXT_0 reporting is a prerequisite for it to work on harts whose device tree declares only "zfh". Tested on a RISC-V QEMU VM whose device tree only declares "zfh" and "zvfh": with this change both /proc/cpuinfo and the hwprobe RISCV_HWPROBE_KEY_IMA_EXT_0 bitmap report ZFHMIN and ZVFHMIN, and the hwprobe selftest (including the new implication check) passes. Link: https://lore.kernel.org/kvm-riscv/20260206002349.96740-1-andrew.jones@oss.qualcomm.com/ Signed-off-by: JinRui Link: https://patch.msgid.link/7190E4DB338251C3+20260811081513.2849980-1-jinrui@haiwei.tech [pjw@kernel.org: trimmed superfluous blank line in tags] Signed-off-by: Paul Walmsley

riscv: hwprobe: initialize pair->value in hwprobe_one_pair()

2026-09-01T01:11:23+00:00

The vendor-extension handlers reached from hwprobe_one_pair() (hwprobe_isa_vendor_ext_thead_0() and friends) only OR the present bits into pair->value via VENDOR_EXTENSION_SUPPORTED() and clear their own missing bits; they assume the caller has already zeroed pair->value. That holds for hwprobe_get_values() (it zeroes each pair) and hwprobe_get_cpus() (it re-initializes its scratch pair per key), but not for complete_hwprobe_vdso_data(), which reuses a single pair across all keys without re-zeroing. A vendor key therefore inherits stale bits from the previously probed key, and the wrong value is cached in the vDSO all_cpu_hwprobe_values[] and handed to userspace on the fast patih. Zero pair->value once at the top of hwprobe_one_pair() so every handler starts from a clean value regardless of the caller, and drop the now redundant zeroing in the *_BLOCK_SIZE cases. hwprobe_isa_ext0() keeps its own zeroing because hwprobe_ext0_has() calls it directly, bypassing hwprobe_one_pair(). Fixes: a5ea53da65c5 ("riscv: hwprobe: Add thead vendor extension probing") Signed-off-by: Andy Chiu Reviewed-by: Jesse Taube Link: https://patch.msgid.link/20260725001614.2578617-2-tchiu@tenstorrent.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley

riscv: use string helper in setup_global_riscv_enable()

2026-09-01T01:11:23+00:00

Prefer the convenient string choice 'str_disabled_enabled()' helper over hardcoded strings in 'setup_global_riscv_enable()'. Signed-off-by: Dmitry Antipov Link: https://patch.msgid.link/20260819160546.3219942-1-dmantipov@yandex.ru Signed-off-by: Paul Walmsley

Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set"

2026-09-01T01:11:23+00:00

This reverts commit 3033b2b1e3949274f33a140e2a97571b5a307298. The reverted patch is userspace-visible behavior change, not a bug fix. The two variables here (pmm and pmlen) control two independent features: pmm is the _hardware_ pointer masking mode that applies while executing in userspace. pmlen is the shift amount that the _kernel_ uses when untagging addresses; PMLEN_0 means no untagging occurs, so the kernel does not accept tagged addresses in syscall arguments. It is valid (as documented and tested by the self test) to enable pointer masking without enabling the tagged address ABI. This separation is necessary to allow userspace to create an execution environment similar to what the kernel supports on arm64 by default, where TBI is enabled but the tagged address ABI is not. (On arm64, there is no equivalent to PR_PMLEN_MASK because TBI is always enabled.) Signed-off-by: Samuel Holland Link: https://patch.msgid.link/20260820014551.1979772-1-samuel.holland@sifive.com Cc: stable@vger.kernel.org Fixes: 3033b2b1e394 ("riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set") Signed-off-by: Paul Walmsley

riscv: patch: skip fixmap mapping when kernel text is already writable

2026-09-01T01:11:23+00:00

patch_map() always creates a temporary writable mapping via fixmap for kernel text addresses, even when CONFIG_STRICT_KERNEL_RWX is disabled and the kernel text is already mapped with _PAGE_WRITE. This is unnecessary overhead at best, and on minimal configurations it can cause page faults. Skip the fixmap path for kernel text when CONFIG_STRICT_KERNEL_RWX is not enabled, since the text pages are already writable in that case. The module text path is already gated on CONFIG_STRICT_MODULE_RWX and is kept unchanged. Reported-by: Klara Modin Closes: https://lore.kernel.org/all/ant_8TaBbov_GS4i@soda.int.kasm.eu/ Reported-by: Lad Prabhakar Closes: https://lore.kernel.org/all/CA+V-a8tQK8rih9SGGTyqrEBGpNkx4H0eX2YccCRrgkVAPr+EBg@mail.gmail.com/ Tested-by: Klara Modin Tested-by: Lad Prabhakar Link: https://patch.msgid.link/20260814082742.148403-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley