summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-08-08powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leakGeorge Wilson1-1/+11
In papr_phy_attest_create_handle(), the params->cmd.length is not validated before use, which can result in a buffer overlow. Check it and return -EINVAL if it is either 0 or exceeds sizeof(params->cmd). Also, params is freed on the success path but not error. Free it on errors after memory allocation. And free it on negative fd. Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for physical-attestation RTAS") Acked-by: Haren Myneni <haren@linux.ibm.com> Acked-by: Nayna Jain <nayna@linux.ibm.com> Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16 Signed-off-by: George Wilson <gcwilson@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
2026-08-07RISC-V: hwprobe: Use BIT macro to avoid warningsJesse Taube1-78/+79
In uapi/asm/hwprobe.h file, (1 << N) is used to define the bit field which causes checkpatch to warn. Use _BITUL(N) and _BITULL(N) to avoid these warnings. Signed-off-by: Jesse Taube <jtaubepe@redhat.com> Link: https://patch.msgid.link/20260805153346.1036988-1-jtaubepe@redhat.com [pjw@kernel.org: updated to apply and to cover new extensions] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: alternative: Also patch the compat vDSOThomas Weißschuh1-0/+5
The vDSO for compat processes can also contain alternative entries. Patch those, too. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260630-riscv-vdso32-alternative-v1-3-a32fd89b7b1c@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: alternative: Use the statically extracted vDSO section offsetsThomas Weißschuh1-17/+11
Currently the alternative sections are extracted from the vDSO binaries at runtime. This has runtime overhead and also doesn't work for the compat vDSO. Use the offsets generated during the build instead, fixing both issues. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260630-riscv-vdso32-alternative-v1-2-a32fd89b7b1c@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: vdso: Add symbols for the alternative section boundariesThomas Weißschuh2-0/+8
Currently the alternative sections are extracted from the vDSO binaries at runtime. This has runtime overhead and also doesn't work for the compat vDSO. Extract the offsets of the alternative section during the build with the existing symbol extraction machinery. Also add dummy symbols as fallback. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260630-riscv-vdso32-alternative-v1-1-a32fd89b7b1c@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobeAndrew Jones4-0/+14
Add Ziccamoa, Ziccif, and Za64rs to riscv_isa_ext[] so they can be parsed from devicetree/ACPI ISA strings. Ziccrse is already present in cpufeature; this patch only adds its hwprobe exposure. Expose all four extensions via hwprobe through new bits in RISCV_HWPROBE_KEY_IMA_EXT_1 (RISCV_HWPROBE_EXT_ZICCAMOA, _ZICCIF, _ZICCRSE, _ZA64RS), so userspace can probe each of these RVA23U64-mandatory extensions individually. Reviewed-by: Jesse Taube <jtaubepe@redhat.com> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-6-2c61f94a695a@gmail.com [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Add Zicclsm to cpufeature and hwprobeJesse Taube4-0/+4
Zicclsm requires misaligned support for all regular load and store instructions, both scalar and vector, but not AMOs or other specialized forms of memory access, to main memory regions with both the cacheability and coherence PMAs, as defined in the profiles spec. Even though mandated, misaligned loads and stores might execute extremely slowly. Standard software distributions should assume their existence only for correctness, not for performance. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Jesse Taube <jesse@rivosinc.com> [andrew.jones: Rebased, rewrote doc text, minor commit message revisions] Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-5-2c61f94a695a@gmail.com [pjw@kernel.org: updated to apply; added Andrew's username to his tag comments] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: cpufeature: Clarify ISA spec version for canonical orderGuodong Xu1-1/+2
Specify that chapter 27 refers to version 20191213 of the RISC-V ISA Unprivileged Architecture. The chapter numbering differs across specification versions - for example, in version 20250508, the ISA Extension Naming Conventions is chapter 36, not chapter 27. Historical versions of the RISC-V specification can be found via Link [1]. Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://riscv.org/specifications/ratified/ [1] Fixes: 99e2266f2460 ("RISC-V: clarify ISA string ordering rules in cpu.c") Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://patch.msgid.link/20260125-supm-ext-id-v2-3-1e3b9714c860@riscstar.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Standardize extension capitalizationCharlie Jenkins9-62/+63
The base extensions are often lowercase and were written as lowercase in hwcap, but other references to these extensions in the kernel are uppercase. Standardize the case to make it easier to handle macro expansion. Acked-by: Anup Patel <anup@brainfault.org> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [andrew.jones: Apply KVM_ISA_EXT_ARR(), fixup all KVM use.] Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-4-2c61f94a695a@gmail.com [pjw@kernel.org: fixed a checkpatch warning; added Andrew's username to his tag comments] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: kprobes: Prevent probes in breakpoint handlersRui Qi1-0/+3
The ftrace selftest multiple_kprobes.tc registers kprobe events on the first 256 text symbols from /proc/kallsyms. If handle_break() is selected as a probe target on RISC-V, the breakpoint exception path can trap again before it reaches the kprobe breakpoint handler. That recursively enters do_trap_break() and can make the system unresponsive. Mark handle_break() and its local probe dispatch helpers as nokprobe symbols so they are added to the kprobe blacklist, matching other low-level breakpoint exception paths. Signed-off-by: Rui Qi <qirui.001@bytedance.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260806043807.2583001-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: cmpxchg: Use .option arch for Zacas and ZabhaVivian Wang2-7/+13
Instead of adding these to -march globally, use .option arch to use instructions from these extensions only in code paths where we know they are available, like how it is done for most other extensions. TOOLCHAIN_HAS_{ZACAS,ZABHA} already depend on AS_HAS_OPTION_ARCH, so this is not a functionality regression even on older assemblers. Although the compiler is unlikely to generate atomics on its own accord, this aligns handling of Zacas and Zabha with most other extensions and improves consistency on how assembly code requiring extra extensions is written in kernel code. This is analogous to the use of __LSE_PREAMBLE or .arch_extension lse in arm64 code. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Reviewed-by: Jesse Taube <jtaubepe@redhat.com> Link: https://patch.msgid.link/20260717-riscv-no-zacas-zabha-in-march-v1-1-82b5b0799fb6@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: acpi: Handle LPI architectural context loss flagsPeixin Xie1-0/+19
Commit 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer") replaced the generic nonzero check for LPI architectural context loss flags with arch_get_idle_state_flags(). RISC-V does not implement the helper, so it falls back to the stub that returns 0. Consequently, CPUIDLE_FLAG_TIMER_STOP is not set when an LPI state loses the hart timer context, preventing cpuidle from using a broadcast timer for that state. Implement the RISC-V helper and map the hart timer context loss flag to CPUIDLE_FLAG_TIMER_STOP. Fixes: 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer") Cc: stable@vger.kernel.org Acked-by: Sudeep Holla <sudeep.holla@kernel.org> Reviewed-by: Yixun Lan <dlan@kernel.org> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Reviewed-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Peixin Xie <peixin.xie@linux.spacemit.com> Link: https://patch.msgid.link/20260803-riscv-acpi-lpi-timer-v3-1-520fa13732f5@linux.spacemit.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: further remove XIPJisheng Zhang4-148/+3
After commit 9b3a2be84803 ("riscv: Remove support for XIP kernel"), something relatd with XIP are still there. Remove them to clean up the code. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260805010049.13918-1-jszhang@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Add support for srmcfg CSR from Ssqosid extensionDrew Fustini7-0/+206
Add support for the srmcfg CSR defined in the Ssqosid ISA extension. The CSR contains two fields: - Resource Control ID (RCID) for resource allocation - Monitoring Counter ID (MCID) for tracking resource usage Requests from a hart to shared resources are tagged with these IDs, allowing resource usage to be associated with the running task. Add a srmcfg field to thread_struct with the same format as the CSR. The context-switch path writes the field to the CSR, and resctrl_arch_set_closid_rmid() updates it when a task is assigned to a resctrl control or monitoring group. A per-cpu cpu_srmcfg_default holds the default srmcfg for each CPU, set by resctrl_arch_set_cpu_default_closid_rmid() on CPU group assignment. On context switch, RCID and MCID inherit from the CPU default independently: a task whose thread RCID field is zero takes the CPU default's RCID, and likewise for MCID. A per-cpu cpu_srmcfg variable mirrors the CSR state to avoid redundant writes. L1D-hot memory access is faster than a CSR read and avoids traps under virtualization. Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 Assisted-by: Claude:claude-opus-4-7 Co-developed-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Drew Fustini <fustini@kernel.org> Link: https://patch.msgid.link/20260729-dfustini-atl-sc-cbqri-dt-v6-3-7c22b05d461b@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Detect the Ssqosid extensionDrew Fustini2-0/+2
Ssqosid is the RISC-V Quality-of-Service (QoS) Identifiers specification which defines the Supervisor Resource Management Configuration (srmcfg) register. Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 Co-developed-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Drew Fustini <fustini@kernel.org> Link: https://patch.msgid.link/20260729-dfustini-atl-sc-cbqri-dt-v6-2-7c22b05d461b@kernel.org [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsingAtish Patra2-0/+26
Smcdeleg extension allows the M-mode to delegate selected counters to S-mode so that it can access those counters and correpsonding hpmevent CSRs without M-mode. Ssccfg (‘Ss’ for Privileged architecture and Supervisor-level extension, ‘ccfg’ for Counter Configuration) provides access to delegated counters and new supervisor-level state. This patch just enables these definitions and enable parsing. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-9-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Ssccfg extension CSR definitionKaiwen Xue1-0/+18
This adds the scountinhibit CSR definition and S-mode accessible hpmevent bits defined by smcdeleg/ssccfg. scountinhibit allows S-mode to start/stop counters directly from S-mode without invoking SBI calls to M-mode. It is also used to figure out the counters delegated to S-mode by the M-mode as well. Signed-off-by: Kaiwen Xue <kaiwenx@rivosinc.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: fixed subject typo] Link: https://patch.msgid.link/20260807-counter_delegation-v9-8-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Smcntrpmf extension parsingAtish Patra2-0/+2
Smcntrpmf extension allows M-mode to enable privilege mode filtering for cycle/instret counters. However, the cyclecfg/instretcfg CSRs are available in Ssccfg only if Smcntrpmf is present. That's why, kernel needs to detect presence of Smcntrpmf extension and enable privilege mode filtering for cycle/instret counters. Reviewed-by: Clément Léger <cleger@rivosinc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-6-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Define indirect CSR access helpersAtish Patra1-0/+50
The indirect CSR requires multiple instructions to read/write CSR. Add a few helper macros for ease of usage. These have to be macros rather than functions. csr_read()/csr_write() stringify their CSR argument into the inline asm template via __ASM_STR(), so the CSR number must be a literal token; passing it as a function parameter emits "csrr %0, iregcsr", which the assembler rejects with "unknown CSR `iregcsr'". The stringification happens in the preprocessor, before inlining or constant propagation, so it cannot be worked around by forcing inlining or by only ever passing constants - gcc 12, gcc 16 and clang 22 all reject it alike. Underneath, csrr/csrw encode the CSR as a 12-bit immediate and RISC-V has no register-indirect form, which is also why asm/csr.h keeps every one of its accessors as a macro. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: expand "ind" abbreviation] Link: https://patch.msgid.link/20260807-counter_delegation-v9-5-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Smcsrind and Sscsrind ISA extension definition and parsingAtish Patra2-0/+6
The S[m|s]csrind extensions extend the indirect CSR access mechanism defined in Smaia/Ssaia extensions. This patch just enables the definition and parsing. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: use official RISC-V extension names in the patch description] Link: https://patch.msgid.link/20260807-counter_delegation-v9-3-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Smcsrind and Sscsrind ISA extension CSR definitionsKaiwen Xue1-0/+30
This adds definitions of new CSRs and bits defined in the Smcsrind and Sscsrind ISA extensions. These CSRs enable the indirect CSR accesses mechanism to access any indirect CSRs in M-, S-, and VS-mode. The range of the select values and ireg will be defined by the ISA extension that are based on the Smcsrind and Sscsrind extensions. Signed-off-by: Kaiwen Xue <kaiwenx@rivosinc.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: clean up the patch description; use official RISC-V extension names] Link: https://patch.msgid.link/20260807-counter_delegation-v9-2-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07Revert "riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"Nam Cao4-72/+13
This reverts commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"). The commit ensures synchronization between the unaligned vector access speed probe kthread and vDSO data read. But now that the kthread has been removed, this commit can be reverted. Signed-off-by: Nam Cao <namcao@linutronix.de> Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Link: https://patch.msgid.link/50ca78a649faf53f8941bc94c9cf8268b3644d38.1781666867.git.namcao@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: unaligned: stop using kthread for check_vector_unaligned_access()Nam Cao1-17/+2
A kthread is used to run check_vector_unaligned_access() to optimize boot time, allowing the kernel to continue booting without waiting for the unaligned vector speed probe to finish. However, this asynchronous approach introduces several complications. First, the kthread may not complete before a user reads vDSO data, resulting in incorrect values. This was previously addressed by commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"), which added complex synchronization between the kthread and vDSO reads. Second, it was discovered that the kthread may not finish before vec_check_unaligned_access_speed_all_cpus() (marked with __init) is freed, triggering a page fault. These issues raise the question of whether the kthread is worth the added complexity. A past boot time regression report was actually unrelated to synchronous probing; it was caused by the probe running serially. Since switching to a parallel probe, no further complaints have been made. Furthermore, the unaligned scalar access speed probe takes the same amount of time, runs synchronously, and has caused no issues. Testing shows no noticeable boot time slowdown when running the vector probe synchronously (0.464474s with kthread vs. 0.457991s without). Remove the kthread usage and run the probe synchronously. This simplifies the boot flow and allows for the revert of commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot") Reported-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Closes: https://lore.kernel.org/linux-riscv/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com/ Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Cc: stable@vger.kernel.org Signed-off-by: Nam Cao <namcao@linutronix.de> Acked-by: Jesse Taube <jtaubepe@redhat.com> Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Link: https://patch.msgid.link/1c378963f27c5960e8a57c50b8b444d30954cb54.1781666867.git.namcao@linutronix.de [pjw@kernel.org: updated to apply; adjusted Fixes: tag; fixed my own manual patch application error] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Mark default_power_off() as __noreturnThorsten Blum1-1/+1
Since default_power_off() never returns, annotate it with the __noreturn attribute to improve compiler optimizations. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260727100339.410466-2-thorsten.blum@linux.dev Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: mm: Move dma_contiguous_reserve() after NUMA initializationEder Zulian1-2/+1
Move the dma_contiguous_reserve() call from setup_bootmem() to misc_mem_init(), placing it after arch_numa_init(). This ensures that NUMA topology is initialized when reserving contiguous memory for DMA. Tested with CMA_SIZE_PERNUMA enabled and two NUMA nodes on QEMU: qemu-system-riscv64 \ -machine virt \ -nographic \ -smp 2 -m 512M \ -numa node,nodeid=0,cpus=0,memdev=m0 \ -numa node,nodeid=1,cpus=1,memdev=m1 \ -object memory-backend-ram,id=m0,size=256M \ -object memory-backend-ram,id=m1,size=256M \ -kernel arch/riscv/boot/Image \ -append "console=ttyS0 earlycon loglevel=7 cma=16M" Unpatched kernel's log (one global CMA pool and no per-nodepools, 16 MiB cma-reserved): [ 0.000000] cma: Reserved 16 MiB at 0x000000009ee00000 ... [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000008fffffff] [ 0.000000] Initmem setup node 1 [mem 0x0000000090000000-0x000000009fffffff] ... [ 0.056397] smp: Brought up 2 nodes, 2 CPUs [ 0.066135] Memory: 449288K/524288K available (12279K kernel code, 5980K rwdata, 6144K rodata, 2467K init, 482K bss, 54504K reserved, 16384K cma-reserved) Patched kernel's log (three CMA pools are created, 48 MiB total), [ 0.000000] cma: Reserved 16 MiB at 0x000000009ee00000 [ 0.000000] cma: Reserved 16 MiB at 0x000000008ee00000 [ 0.000000] cma: Reserved 16 MiB at 0x000000009de00000 ... [ 0.054251] smp: Brought up 2 nodes, 2 CPUs [ 0.064082] Memory: 416520K/524288K available (12279K kernel code, 5980K rwdata, 6144K rodata, 2467K init, 482K bss, 54504K reserved, 49152K cma-reserved) Signed-off-by: Eder Zulian <ezulian@redhat.com> Link: https://patch.msgid.link/20260714185648.1082483-1-ezulian@redhat.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: cfi: reduce shadow stack size limit from 2GB to 512MBZong Li1-2/+2
Change the shadow stack size calculation from RLIMIT_STACK/2 (capped at 2GB) to RLIMIT_STACK/8 (capped at 512MB), following David Laight's analysis and recommendation. Rationale: David Laight pointed out that the focus should be on the ratio between shadow stack size and the normal stack size, rather than just the absolute upper limit. His analysis showed that while there are many functions with small stack frames, the majority have stack deltas of over 64 bytes due to saved registers and local variables. Shadow stacks only store return addresses (8 bytes per entry on 64-bit systems), whereas normal stack frames typically consume 64+ bytes. This 8:64 byte ratio means that programs using a lot of stack space are dominated by large buffer allocations and local variables, not extreme recursion depths with minimal local data. For example, with the default RLIMIT_STACK of 8MB: - RLIMIT_STACK/2 gives a 4MB shadow stack supporting 512K nested calls - RLIMIT_STACK/8 gives a 1MB shadow stack supporting 128K nested calls Given typical stack frame sizes of 64+ bytes, RLIMIT_STACK/8 is still conservative and provides adequate depth for practical applications. David noted that this could even be safely halved again. This reduction also better accommodates memory-constrained platforms. On systems with limited physical memory, allocating large shadow stacks can cause virtual memory allocation failures when overcommit mode is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER. Suggested-by: David Laight <david.laight.linux@gmail.com> Link: https://lore.kernel.org/all/20260518105725.7afe7a4c@pumpkin/ Signed-off-by: Zong Li <zong.li@sifive.com> Link: https://patch.msgid.link/20260522093634.3530233-1-zong.li@sifive.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: vdso: Simplify cflags remove logicThomas Weißschuh1-5/+2
Listing all flags for each object file is tedious and error-prone. Replace it with a simpler solution. Link: https://lore.kernel.org/all/20260630135316-f26f0e0f-c08c-4d4d-9963-10f9985a7689@linutronix.de/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260701-riscv-vdso-lto-v1-2-89db0cd82077@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: mm: Apply Svinval in update_mmu_cache()Xu Lu3-18/+26
Use Svinval in update_mmu_cache_range() when the extension is available. Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Link: https://patch.msgid.link/20260715132009.10634-3-luxu.kernel@bytedance.com Tested-by: Klara Modin <klarasmodin@gmail.com> Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: mm: Use ASID in update_mmu_cache()Xu Lu3-6/+8
Only flush TLB entries for the specified mm in update_mmu_cache_range(). Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Link: https://patch.msgid.link/20260715132009.10634-2-luxu.kernel@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: kprobes: add test case for c.jal instruction simulationNam Cao1-0/+24
Add a test case validating that kprobes correctly simulates the c.jal instruction on RV32. The test uses two probe points: a forward c.jal and a backward c.jal, and verifies that the containing function returns the expected magic value KPROBE_TEST_MAGIC after kprobe interception. Co-developed-by: Xiaofeng Yuan <xiaofengmian@163.com> Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260701081033.49871-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: probes: simulate c.jal instructionXiaofeng Yuan3-1/+9
The c.jal instruction is currently marked REJECTED in kprobes instruction decoding, but it should be SIMULATED like other compressed jump instructions. Add simulate_c_jal() which saves the return address to RA and sets the program counter to the target offset, reusing simulate_c_j for the common jump logic. Although c.jal is RV32-only, the function compiles unconditionally. On RV64, riscv_insn_is_c_jal() always returns 0, so the simulation code is never invoked and the small overhead in kernel size is acceptable. Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Tested-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260701081033.49871-2-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: acpi: Enable ARCH_HAS_ACPI_TABLE_UPGRADEVivian Wang4-0/+10
Implement the various required hooks and enable ARCH_HAS_ACPI_TABLE_UPGRADE to allow use for ACPI_TABLE_UPGRADE, which is useful for debugging ACPI table problems. The implementation is based on arm64's of the same feature due to the similarities of the requirements of the two platforms. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260616-riscv-acpi-table-upgrade-v1-2-45902d2dedf9@iscas.ac.cn [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Restart via EFI runtime services when availableAtish Patra1-0/+7
Firmware-preferred reset and EFI capsule update support requires reset via EFI runtime services rather than direction M-mode firmware invocation via SBI. Unlike poweroff, restart mechanism is directly controlled from machine_restart function though. Prefer the EFI runtime ResetSystem() service for restart when UEFI runtime services are available. Signed-off-by: Atish Patra <atishp@meta.com> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260615-efi_reset_shutdown-v1-2-9414edcbbab0@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: efi: Power off via EFI runtime services when availableAtish Patra1-0/+5
When booted via UEFI with runtime services enabled, EFI Reset Shutdown is the firmware-preferred shutdown path: it lets firmware run its own shutdown hooks which may invoke SBI SRST extension internally. However, RISC-V always powers off via the SBI SRST extension today and EFI runtime path is never used even when firmware provides it. Enable the poweroff via EFI by overriding efi_poweroff_required() Signed-off-by: Atish Patra <atishp@meta.com> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260615-efi_reset_shutdown-v1-1-9414edcbbab0@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: hwprobe: Register unaligned probes before usermodeRui Qi1-1/+7
The hwprobe vDSO data is populated by the first riscv_hwprobe syscall. Some values, such as MISALIGNED_VECTOR_PERF, may depend on the async vector unaligned access speed probe registered by check_unaligned_access_all_cpus(). That initcall currently runs at late_initcall level. However, rootfs_initcall enables usermode helpers before late initcalls run, so an early helper can execute userspace and call riscv_hwprobe first. In that case complete_hwprobe_vdso_data() consumes the initial pending_boot_probes reference, populates the vDSO cache, and marks it ready before the later async probe is registered. The eventual probe result then cannot update the already-ready cache. Move check_unaligned_access_all_cpus() to fs_initcall_sync. This still runs after clocksource_done_booting(), so the ktime_get_mono_fast_ns() benchmark uses a stable clocksource, but it runs before rootfs_initcall enables usermode helpers. Any async hwprobe probe is therefore registered before userspace can trigger the one-time vDSO cache population. Cc: stable@vger.kernel.org Fixes: 6455c6c11827 ("riscv: Clean up & optimize unaligned scalar access probe") Signed-off-by: Rui Qi <qirui.001@bytedance.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260721150511.1607105-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.2-rc7Daniel Borkmann88-372/+784
Cross-merge BPF and other fixes after downstream PR. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2026-08-07Merge branches 'thermal-core', 'thermal-hwmon', 'thermal-intel' and ↵Rafael J. Wysocki2-0/+4
'thermal-tools' Merge updates of the thermal core, thermal drivers for Intel platforms and the thermometer utility for 7.3-rc1: - Use sysfs_emit_at() in trans_table_show() (Thorsten Blum) - Remove hwmon class devices created for thermal zones when the thermal zone devices holding them are removed (Rafael Wysocki) - Add support for the Directed Package-level Thermal Interrupt to the Intel thermal throttling driver to allow package-level thermal interrupts to go to one specific CPU in a processor package instead of going to all of the CPUs in it (Ricardo Neri) - Clean up RFIM groups on DVFS failure and clean up ODVP on probe failures in the int340x thermal driver (Pengpeng Hou) - Remove redundant dev_err() from the int340x thermal driver and the bxt_pmic driver (Pan Chuang) - Simplify ptc_temperature_write() in the int340x thermal driver by using kstrtou32_from_user() (Dmitry Antipov) - Close fd on realloc() failure in the thermometer utility (Amarjeet) * thermal-core: thermal: sysfs: Use sysfs_emit_at() in trans_table_show() * thermal-hwmon: thermal: hwmon: Remove hwmon class device along with its parent * thermal-intel: thermal: intel: int340x: simplify ptc_temperature_write() thermal: intel: bxt_pmic: Remove redundant dev_err() thermal: intel: int340x: Remove redundant dev_err() thermal: intel: int3400: clean up ODVP on probe failures thermal: intel: int340x: clean up RFIM groups on DVFS failure thermal: intel: Add a syscore shutdown callback for kexec reboot thermal: intel: Add syscore callbacks for suspend and resume thermal: intel: Enable the Directed Package-level Thermal Interrupt thermal: intel: Add resources to handle directed package-level thermal interrupts x86/thermal: Add bit definitions for Intel Directed Package Thermal Interrupt * thermal-tools: tools/thermal/thermometer: close fd on realloc() failure
2026-08-07Merge branch 'acpi-irqchip'Rafael J. Wysocki1-0/+1
Merge irqchip changes related to ACPI support that are needed to enable GICv5 IWB ACPI probe ordering detection on ARM, including the addition of acpi_device_clear_deps() and RISC-V interrupt controller management code refactoring to extract generic code from it into the common ACPI IRQ code (Lorenzo Pieralisi) * acpi-irqchip: irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection ACPI/IORT: Implement ACPI infrastructure to enable GICv5 IWB probe deferral ACPI: irq: Move RISC-V interrupt controllers autodep to ACPI IRQ code ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep() ACPI: RISC-V: Fix riscv_acpi_irq_get_dep() loop termination ACPI: Add acpi_device_clear_deps() helper function
2026-08-07x86/locking: Use sfence for wmb() if SSE is availableYao Zi1-1/+1
When adding cc clobber to wmb()'s definition, the alternative() condition to use sfence was incorrectly raised from X86_FEATURE_XMM to X86_FEATURE_XMM2. Restore the correct constraint for potential better performance on machines without SSE2. Fixes: bd922477d935 ("locking/x86: Add cc clobber for ADDL") Signed-off-by: Yao Zi <me@ziyao.cc> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260801182953.15069-1-me@ziyao.cc
2026-08-07perf/x86/intel/pt: Fix stop/start with no updateAdrian Hunter1-9/+36
If pt_event_stop() is called without PERF_EF_UPDATE flag, then perf_aux_output_end() is not called. A subsequent call to pt_event_start() will call perf_aux_output_begin() again which violates the rule against nesting and triggers a WARNING in perf_aux_output_begin(). Originally, pt_event_stop() was never called without PERF_EF_UPDATE, because the only code paths to do so are from event overflow, and Intel PT does not do that. However the introduction of group throttling by commit 9734e25fbf5ae ("perf: Fix the throttle logic for a group") meant that an Intel PT event could be throttled if it was part of a group. Throttling calls PMU ->stop() / ->start() callbacks without flags. An example is when AUX area sampling is used. The following commands hit the issue: echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate perf record -F32000 --aux-sample -e '{intel_pt//u,cycles:u}' \ -- bash -c 'for i in `seq 1 100000` ; do true ; done' Use PERF_HES_UPTODATE to track whether perf_aux_output_begin() and perf_aux_output_end() are balanced. A cleared PERF_HES_UPTODATE bit indicates that an AUX output context is still open. Amend pt_event_start() / pt_event_stop() accordingly so that begin/end stay balanced: - In non-snapshot mode, stop() always closes the buffer (the buffer may have run out of space, and that accounting is done by the update), so a following start() opens a fresh one as before. - In snapshot/overwrite mode, stop() without PERF_EF_UPDATE leaves the buffer open so that pt_event_snapshot_aux() can still copy from it, and start() then only re-enables tracing instead of calling perf_aux_output_begin() again. Note that pt_event_del() calls pt_event_stop() with PERF_EF_UPDATE flag set (as is required by the documentation), so a final call to perf_aux_output_end() is assured. Fixes: 52ca9ced3f707 ("perf/x86/intel/pt: Add Intel PT PMU driver") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Yi Lai <yi1.lai@intel.com> Link: https://patch.msgid.link/20260721070254.13557-4-adrian.hunter@intel.com
2026-08-07perf/x86/intel/pt: Use bitwise access for PERF_HES_STOPPEDAdrian Hunter1-8/+8
The Intel PT driver reads and writes event->hw.state as a whole value, assuming it is either 0 or PERF_HES_STOPPED. That is true today, but a subsequent fix needs to also track an open AUX output buffer using the PERF_HES_UPTODATE bit of the same field. When more than one bit can be set, whole-value assignments would overwrite the other bits and whole-value comparisons would fail to match. Convert all accesses to set, clear and test the PERF_HES_STOPPED bit individually, in preparation for that change. No functional change intended: event->hw.state currently only ever holds 0 or PERF_HES_STOPPED, so the bitwise forms are equivalent. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Yi Lai <yi1.lai@intel.com> Link: https://patch.msgid.link/20260721070254.13557-3-adrian.hunter@intel.com
2026-08-07perf/x86/intel/pt: Factor out pt_config_enable()Adrian Hunter1-17/+24
pt_config() enables tracing by allowing NMIs and pause/resume, issuing the necessary barriers, and calling pt_config_start(). A later change needs to re-enable tracing on a (re-)start path without repeating the full pt_config() setup (filters, RTIT_CTL, buffer configuration). Factor that enabling sequence out into a new helper, pt_config_enable(), so it can be called on its own. No functional change intended. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Yi Lai <yi1.lai@intel.com> Link: https://patch.msgid.link/20260721070254.13557-2-adrian.hunter@intel.com
2026-08-07KVM: x86: Remove runtime Xen TSC frequency CPUID updateDavid Woodhouse2-29/+0
Remove the code in kvm_cpuid() that dynamically updates the Xen TSC info CPUID leaf at runtime, as KVM is updating the wrong sub-leaf anyway (0x40000x03/2 EAX is the *host* TSC frequency per the Xen ABI, not the guest frequency which belongs in 0x40000x03/0 ECX). Simply drop the code instead of fixing it to fill the correct sub-leaf, as modifying guest CPUID entries/output at runtime is generally undesirable, and providing userspace the necessary data to fill the sub-leaf itself is useful for other reasons, e.g. to fill the generic 0x40000010 timing leaf and to provide exact scaling information to aid save/restore. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Link: https://patch.msgid.link/20260728144954.355376-23-dwmw2@infradead.org [sean: tweak changelog to take this patch before the new uAPI] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-08-07KVM: x86/xen: Prevent runstate times from becoming negativeDavid Woodhouse1-6/+22
When kvm_xen_update_runstate() is invoked to set a vCPU's runstate, the time spent in the previous runstate is accounted. This is based on the delta between the current KVM clock time, and the previous value stored in vcpu->arch.xen.runstate_entry_time. If the KVM clock goes backwards, that delta will be negative. Or, since it's an unsigned 64-bit integer, very *large*. Linux guests deal with that particularly badly, reporting 100% steal time for ever more (well, for *centuries* at least, until the delta has been consumed). So when a negative delta is detected, just refrain from updating the runstate times until the KVM clock catches up with runstate_entry_time again. Also clamp steal_ns to delta_ns to prevent steal time from exceeding the total elapsed time, and handle negative steal_ns (which can happen if run_delay goes backwards across a scheduler update). The userspace APIs for setting the runstate times do not allow them to be set past the current KVM clock, but userspace can still adjust the KVM clock *after* setting the runstate times, which would cause this situation to occur. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Link: https://patch.msgid.link/20260728144954.355376-21-dwmw2@infradead.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-08-07KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tablesQihang1-3/+9
vgic_v3_save_pending_tables() iterates dist->lpi_xa using xa_for_each() and dereferences the returned struct vgic_irq in the loop body without holding a reference on the LPI. The xarray iterator only provides temporary RCU coverage while looking up the current entry. That is not sufficient for this loop body, which reads fields from struct vgic_irq and performs guest memory accesses before the iteration completes. A concurrent path can trigger this race: the irqfd cached injection path (vgic_its_inject_cached_translation) obtains a transient LPI reference via vgic_its_check_cache() without holding kvm->lock, vcpu->mutex, config_lock, or its_lock. If guest ITS DISCARD then drops the cache and ITE references under its_lock, the transient inject reference may become the final one. When vgic_put_irq() drops it, the LPI is erased from lpi_xa and freed via kfree_rcu(). Meanwhile, vgic_v3_save_pending_tables() may still hold a stale pointer obtained from the xarray iterator and dereference it after the RCU grace period completes. Fix this by re-fetching each iterated LPI via vgic_get_irq(), which takes a stable reference, and dropping it with vgic_put_irq() on all paths. This matches the pattern already used by other lpi_xa iterators in the vgic ITS code. Cc: stable@vger.kernel.org Signed-off-by: Qihang <q.h.hack.winter@gmail.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260807025534.34125-1-q.h.hack.winter@gmail.com Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-08-07KVM: arm64: vgic-its: Point saved ITEs at the next valid entryFuad Tabba1-7/+8
An ITE whose collection was dropped is saved as an invalid entry, and vgic_its_restore_ite() has no offset to follow from one, so the scan steps a single entry at a time until it reaches a valid entry or the end of the ITT. Compute the offset to the next ITE that is saved as valid instead. Suggested-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260807104102.2410744-5-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-08-07KVM: arm64: vgic-its: Don't save collections the table cannot holdFuad Tabba1-0/+3
A guest that disables the ITS and rewrites GITS_BASER with fewer pages, VALID still set, keeps every collection it mapped against the larger table: KVM stores the new BASER unconditionally and frees the list only when VALID is cleared. vgic_its_save_collection_table() then walks the whole list, writing up to 448K past the end of the table, and saves collection IDs that vgic_its_restore_cte() rejects, so the save succeeds and the restore fails with -EINVAL on the destination. The overrun stays in guest memory, as vgic_write_guest_lock() validates every gfn. Validate each collection against the current table with vgic_its_check_id() and return -EINVAL, as vgic_its_save_device_tables() does for devices. Collection IDs are unique and the collection table is never indirect, so the check also bounds the walk. Fixes: ea1ad53e1e31a ("KVM: arm64: vgic-its: Collection table save/restore") Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260807104102.2410744-4-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-08-07KVM: arm64: vgic: Don't leak the SPI array when init is retriedFuad Tabba1-0/+3
Nothing latches a failed vgic_init(), so userspace can retry KVM_DEV_ARM_VGIC_CTRL_INIT after a failure past kvm_vgic_dist_init(). kvm_vgic_setup_default_irq_routing() is the reachable case, running on every configuration. Each retry overwrites dist->spis and only the last allocation is freed at teardown, leaking up to 960 struct vgic_irq, about 90KB, per attempt. Return early when the array is already allocated, as vgic_allocate_private_irqs_locked() and vgic_v4_init() do. Fixes: ad275b8bb1e65 ("KVM: arm/arm64: vgic-new: vgic_init: implement vgic_init") Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260807104102.2410744-3-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-08-07KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT saveFuad Tabba1-0/+8
MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have. Fixes: eff484e0298da ("KVM: arm64: vgic-its: ITT save and restore") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260807104102.2410744-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-08-07x86/paravirt: Trace contended_release on unlockDmitry Ilvokhin2-2/+53
On PARAVIRT_SPINLOCKS=y kernels queued_spin_unlock() is dispatched through a static_call(). Those PARAVIRT_SPINLOCKS=y kernels are quite popular. Gating contended_release behind a static branch would leave a NOP on the unlock hot path even, when the tracepoint is disabled. Since the static_call() is already present, swap its target to a traced unlock, when the tracepoint is enabled instead. When contended_release tracepoint is disabled the target is the plain unlock (an inline store on native x86_64), so the unlock path is unchanged and the tracepoint is truly zero-cost. Provide two traced variants, native_queued_spin_unlock_traced() and pv_queued_spin_unlock_traced(), so each tail-calls its own base unlock directly rather than recursing through the now-traced static_call(). Teach pv_is_native_spin_unlock() that the traced native variant still counts as native. Only PARAVIRT_SPINLOCKS=y is affected. PARAVIRT_SPINLOCKS=n keeps the generic static-branch path. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juergen Gross <jgross@suse.com> Link: https://patch.msgid.link/17fa67f9fa4cf93f1150725e89f5f916e41a9b6f.1785778551.git.d@ilvokhin.com
generated by cgit (git 2.54.0.dirty) at 2026-09-21 17:51:09 +0000