summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-29kselftest/riscv: add kselftest for user mode CFIDeepak Gupta
Add a kselftest for RISC-V control flow integrity implementation for user mode. There is not a lot going on in the kernel to enable landing pad for user mode. CFI selftests are intended to be compiled with a zicfilp and zicfiss enabled compiler. This kselftest simply checks if landing pads and shadow stacks for the process are enabled or not and executes ptrace selftests on CFI. The selftest then registers a SIGSEGV signal handler. Any control flow violations are reported as SIGSEGV with si_code = SEGV_CPERR. The test will fail on receiving any SEGV_CPERR. The shadow stack part has more changes in the kernel, and thus there are separate tests for that. - Exercise 'map_shadow_stack' syscall - 'fork' test to make sure COW works for shadow stack pages - gup tests Kernel uses FOLL_FORCE when access happens to memory via /proc/<pid>/mem. Not breaking that for shadow stack. - signal test. Make sure signal delivery results in token creation on shadow stack and consumes (and verifies) token on sigreturn - shadow stack protection test. attempts to write using regular store instruction on shadow stack memory must result in access faults - ptrace test: adds landing pad violation, clears ELP and continues In case the toolchain doesn't support the CFI extension, the CFI kselftest won't be built. Test output =========== """ TAP version 13 1..5 This is to ensure shadow stack is indeed enabled and working This is to ensure shadow stack is indeed enabled and working ok 1 shstk fork test ok 2 map shadow stack syscall ok 3 shadow stack gup tests ok 4 shadow stack signal tests ok 5 memory protections of shadow stack memory """ Suggested-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-28-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; cleaned up patch description, code comments] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv: add documentation for shadow stackDeepak Gupta
Add documentation on shadow stack for user mode on riscv and the kernel interfaces exposed for user tasks to enable it. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-27-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up the documentation, patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv: add documentation for landing pad / indirect branch trackingDeepak Gupta
Add documentation on landing pad aka indirect branch tracking on riscv and the kernel interfaces exposed for user tasks to enable it. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-26-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up the documentation] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv: create a Kconfig fragment for shadow stack and landing pad supportDeepak Gupta
This patch creates a Kconfig fragment for shadow stack support and landing pad instruction support. Shadow stack support and landing pad instruction support can be enabled by selecting 'CONFIG_RISCV_USER_CFI'. Selecting 'CONFIG_RISCV_USER_CFI' wires up the path to enumerate CPU support. If support exists, the kernel will support CPU-assisted user mode CFI. If CONFIG_RISCV_USER_CFI is selected, select 'ARCH_USES_HIGH_VMA_FLAGS', 'ARCH_HAS_USER_SHADOW_STACK' and 'DYNAMIC_SIGFRAME' for riscv. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-25-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description, Kconfig text; added CONFIG_MMU exclusion] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29arch/riscv: add dual vdso creation logic and select vdso based on hwDeepak Gupta
Shadow stack instructions are taken from the Zimop ISA extension, which is mandated on RVA23. Any userspace with shadow stack instructions in it will fault on hardware that doesn't have support for Zimop. Thus, a shadow stack-enabled userspace can't be run on hardware that doesn't support Zimop. It's not known how Linux userspace providers will respond to this kind of binary fragmentation. In order to keep kernel portable across different hardware, 'arch/riscv/kernel/vdso_cfi' is created which has Makefile logic to compile 'arch/riscv/kernel/vdso' sources with CFI flags, and 'arch/riscv/kernel/vdso.c' is modified to select the appropriate vdso depending on whether the underlying CPU implements the Zimop extension. Since the offset of vdso symbols will change due to having two different vdso binaries, there is added logic to include a new generated vdso offset header and dynamically select the offset (like for rt_sigreturn). Signed-off-by: Deepak Gupta <debug@rivosinc.com> Acked-by: Charles Mirabile <cmirabil@redhat.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-24-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29arch/riscv: compile vdso with landing pad and shadow stack noteJim Shu
User mode tasks compiled with Zicfilp may call indirectly into the vdso (like hwprobe indirect calls). Add support for compiling landing pads into the vdso. Landing pad instructions in the vdso will be no-ops for tasks which have not enabled landing pads. Furthermore, add support for the C sources of the vdso to be compiled with shadow stack and landing pads enabled as well. Landing pad and shadow stack instructions are emitted only when the VDSO_CFI cflags option is defined during compile. Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-23-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description, issues reported by checkpatch] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv: enable kernel access to shadow stack memory via the FWFT SBI callDeepak Gupta
The kernel has to perform shadow stack operations on the user shadow stack. During signal delivery and sigreturn, the shadow stack token must be created and validated respectively. Thus shadow stack access for the kernel must be enabled. In the future, when kernel shadow stacks are enabled, they must be enabled as early as possible for better coverage and to prevent any imbalance between the regular stack and the shadow stack. After 'relocate_enable_mmu' has completed, this is the earliest that it can be enabled. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-22-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; cleaned up commit message] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv: add kernel command line option to opt out of user CFIDeepak Gupta
Add a kernel command line option to disable part or all of user CFI. User backward CFI and forward CFI can be controlled independently. The kernel command line parameter "riscv_nousercfi" can take the following values: - "all" : Disable forward and backward cfi both - "bcfi" : Disable backward cfi - "fcfi" : Disable forward cfi Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-21-b55691eacf4f@rivosinc.com [pjw@kernel.org: fixed warnings from checkpatch; cleaned up patch description, doc, printk text] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv/hwprobe: add zicfilp / zicfiss enumeration in hwprobeDeepak Gupta
Add enumeration of the zicfilp and zicfiss extensions in the hwprobe syscall. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-20-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; extend into RISCV_HWPROBE_KEY_IMA_EXT_1; clean patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv: hwprobe: add support for RISCV_HWPROBE_KEY_IMA_EXT_1Paul Walmsley
We've run out of bits to describe RISC-V ISA extensions in our initial hwprobe key, RISCV_HWPROBE_KEY_IMA_EXT_0. So, let's add RISCV_HWPROBE_KEY_IMA_EXT_1, along with the framework to set the appropriate hwprobe tuple, and add testing for it. Based on a suggestion from Andrew Jones <andrew.jones@oss.qualcomm.com>, also fix the documentation for RISCV_HWPROBE_KEY_IMA_EXT_0. Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv/ptrace: expose riscv CFI status and state via ptrace and in core filesDeepak Gupta
Expose a new register type NT_RISCV_USER_CFI for risc-v CFI status and state. Intentionally, both landing pad and shadow stack status and state are rolled into the CFI state. Creating two different NT_RISCV_USER_XXX would not be useful and would waste a note type. Enabling, disabling and locking the CFI feature is not allowed via ptrace set interface. However, setting 'elp' state or setting shadow stack pointer are allowed via the ptrace set interface. It is expected that 'gdb' might need to fixup 'elp' state or 'shadow stack' pointer. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-19-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; cleaned patch description and comments; addressed checkpatch issues] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv/kernel: update __show_regs() to print shadow stack registerDeepak Gupta
Update __show_regs() to print the captured shadow stack pointer. On tasks where shadow stack is disabled, simply print 0. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-18-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv/signal: save and restore the shadow stack on a signalDeepak Gupta
Save the shadow stack pointer in the sigcontext structure when delivering a signal. Restore the shadow stack pointer from sigcontext on sigreturn. As part of the save operation, the kernel uses the 'ssamoswap' instruction to save a snapshot of the current shadow stack on the shadow stack itself (this can be called a "save token"). During restore on sigreturn, the kernel retrieves the save token from the top of the shadow stack and validates it. This ensures that user mode can't arbitrarily pivot to any shadow stack address without having a token and thus provides a strong security assurance during the window between signal delivery and sigreturn. Use an ABI-compatible way of saving/restoring the shadow stack pointer into the signal stack. This follows the vector extension, where extra registers are placed in a form of extension header + extension body in the stack. The extension header indicates the size of the extra architectural states plus the size of header itself, and a magic identifier for the extension. Then, the extension body contains the new architectural states in the form defined by uapi. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-17-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned patch description, code comments; resolved checkpatch warning] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv/traps: Introduce software check exception and uprobe handlingDeepak Gupta
The Zicfiss and Zicfilp extensions introduce a new exception, the 'software check exception', in the privileged ISA, with cause code = 18. This patch implements support for software check exceptions. Additionally, the patch implements a CFI violation handler which checks the code in the xtval register. If xtval=2, the software check exception happened because of an indirect branch that didn't land on a 4 byte aligned PC or on a 'lpad' instruction, or the label value embedded in 'lpad' didn't match the label value set in the x7 register. If xtval=3, the software check exception happened due to a mismatch between the link register (x1 or x5) and the top of shadow stack (on execution of `sspopchk`). In case of a CFI violation, SIGSEGV is raised with code=SEGV_CPERR. SEGV_CPERR was introduced by the x86 shadow stack patches. To keep uprobes working, handle the uprobe event first before reporting the CFI violation in the software check exception handler. This is because, when the landing pad is activated, if the uprobe point is set at the lpad instruction at the beginning of a function, the system triggers a software check exception instead of an ebreak exception due to the exception priority. This would prevent uprobe from working. Reviewed-by: Zong Li <zong.li@sifive.com> Co-developed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-15-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up the patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv: Implement indirect branch tracking prctlsDeepak Gupta
This patch adds a RISC-V implementation of the following prctls: PR_SET_INDIR_BR_LP_STATUS, PR_GET_INDIR_BR_LP_STATUS and PR_LOCK_INDIR_BR_LP_STATUS. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-14-b55691eacf4f@rivosinc.com [pjw@kernel.org: clean up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29prctl: add arch-agnostic prctl()s for indirect branch trackingDeepak Gupta
Three architectures (x86, aarch64, riscv) have support for indirect branch tracking feature in a very similar fashion. On a very high level, indirect branch tracking is a CPU feature where CPU tracks branches which use a memory operand to transfer control. As part of this tracking, during an indirect branch, the CPU expects a landing pad instruction on the target PC, and if not found, the CPU raises some fault (architecture-dependent). x86 landing pad instr - 'ENDBRANCH' arch64 landing pad instr - 'BTI' riscv landing instr - 'lpad' Given that three major architectures have support for indirect branch tracking, this patch creates architecture-agnostic 'prctls' to allow userspace to control this feature. They are: - PR_GET_INDIR_BR_LP_STATUS: Get the current configured status for indirect branch tracking. - PR_SET_INDIR_BR_LP_STATUS: Set the configuration for indirect branch tracking. The following status options are allowed: - PR_INDIR_BR_LP_ENABLE: Enables indirect branch tracking on user thread. - PR_INDIR_BR_LP_DISABLE: Disables indirect branch tracking on user thread. - PR_LOCK_INDIR_BR_LP_STATUS: Locks configured status for indirect branch tracking for user thread. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-13-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description, code comments] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv: Implement arch-agnostic shadow stack prctlsDeepak Gupta
Implement an architecture-agnostic prctl() interface for setting and getting shadow stack status. The prctls implemented are PR_GET_SHADOW_STACK_STATUS, PR_SET_SHADOW_STACK_STATUS and PR_LOCK_SHADOW_STACK_STATUS. As part of PR_SET_SHADOW_STACK_STATUS/PR_GET_SHADOW_STACK_STATUS, only PR_SHADOW_STACK_ENABLE is implemented because RISCV allows each mode to write to their own shadow stack using 'sspush' or 'ssamoswap'. PR_LOCK_SHADOW_STACK_STATUS locks the current shadow stack enablement configuration. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-12-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv/shstk: If needed allocate a new shadow stack on cloneDeepak Gupta
Userspace specifies CLONE_VM to share address space and spawn new thread. 'clone' allows userspace to specify a new stack for a new thread. However there is no way to specify a new shadow stack base address without changing the API. This patch allocates a new shadow stack whenever CLONE_VM is given. In case of CLONE_VFORK, the parent is suspended until the child finishes; thus the child can use the parent's shadow stack. In case of !CLONE_VM, COW kicks in because entire address space is copied from parent to child. 'clone3' is extensible and can provide mechanisms for specifying the shadow stack as an input parameter. This is not settled yet and is being extensively discussed on the mailing list. Once that's settled, this code should be adapted. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-11-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-29riscv/mm: Implement map_shadow_stack() syscallDeepak Gupta
As discussed extensively in the changelog for the addition of this syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the existing mmap() and madvise() syscalls do not map entirely well onto the security requirements for shadow stack memory since they lead to windows where memory is allocated but not yet protected or stacks which are not properly and safely initialised. Instead a new syscall map_shadow_stack() has been defined which allocates and initialises a shadow stack page. This patch implements this syscall for riscv. riscv doesn't require tokens to be setup by kernel because user mode can do that by itself. However to provide compatibility and portability with other architectues, user mode can specify token set flag. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-10-b55691eacf4f@rivosinc.com Link: https://lore.kernel.org/linux-riscv/aXfRPJvoSsOW8AwM@debug.ba.rivosinc.com/ [pjw@kernel.org: added allocate_shadow_stack() fix per Deepak; fixed bug found by sparse] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv/mm: update write protect to work on shadow stacksDeepak Gupta
'fork' implements copy-on-write (COW) by making pages readonly in both child and parent. ptep_set_wrprotect() and pte_wrprotect() clear _PAGE_WRITE in PTE. The assumption is that the page is readable and, on a fault, copy-on-write happens. To implement COW on shadow stack pages, clearing the W bit makes them XWR = 000. This will result in the wrong PTE setting, which allows no permissions, but with V=1 and the PFN field pointing to the final page. Instead, the desired behavior is to turn it into a readable page, take an access (load/store) fault on sspush/sspop (shadow stack) and then perform COW on such pages. This way regular reads would still be allowed and not lead to COW maintaining current behavior of COW on non-shadow stack but writeable memory. On the other hand, this doesn't interfere with existing COW for read-write memory. The assumption is always that _PAGE_READ must have been set, and thus, setting _PAGE_READ is harmless. Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-9-b55691eacf4f@rivosinc.com [pjw@kernel.org: clarify patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv/mm: teach pte_mkwrite to manufacture shadow stack PTEsDeepak Gupta
pte_mkwrite() creates PTEs with WRITE encodings for the underlying architecture. The underlying architecture can have two types of writeable mappings: one that can be written using regular store instructions, and another one that can only be written using specialized store instructions (like shadow stack stores). pte_mkwrite can select write PTE encoding based on VMA range (i.e. VM_SHADOW_STACK) Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-8-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv/mm: manufacture shadow stack ptesDeepak Gupta
This patch implements the creation of a shadow stack pte on riscv. Creating shadow stack PTE on riscv means clearing RWX and then setting W=1. Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-7-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv/mm: ensure PROT_WRITE leads to VM_READ | VM_WRITEDeepak Gupta
'arch_calc_vm_prot_bits' is implemented on risc-v to return VM_READ | VM_WRITE if PROT_WRITE is specified. Similarly 'riscv_sys_mmap' is updated to convert all incoming PROT_WRITE to (PROT_WRITE | PROT_READ). This is to make sure that any existing apps using PROT_WRITE still work. Earlier 'protection_map[VM_WRITE]' used to pick read-write PTE encodings. Now 'protection_map[VM_WRITE]' will always pick PAGE_SHADOWSTACK PTE encodings for shadow stack. The above changes ensure that existing apps continue to work because underneath, the kernel will be picking 'protection_map[VM_WRITE|VM_READ]' PTE encodings. Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-6-b55691eacf4f@rivosinc.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv: Add usercfi state for task and save/restore of CSR_SSP on trap entry/exitDeepak Gupta
Carve out space in the RISC-V architecture-specific thread struct for cfi status and shadow stack in usermode. This patch: - defines a new structure cfi_status with status bit for cfi feature - defines shadow stack pointer, base and size in cfi_status structure - defines offsets to new member fields in thread in asm-offsets.c - saves and restores shadow stack pointer on trap entry (U --> S) and exit (S --> U) Shadow stack save/restore is gated on feature availability and is implemented using alternatives. CSR_SSP can be context-switched in 'switch_to' as well, but as soon as kernel shadow stack support gets rolled in, the shadow stack pointer will need to be switched at trap entry/exit point (much like 'sp'). It can be argued that a kernel using a shadow stack deployment scenario may not be as prevalent as user mode using this feature. But even if there is some minimal deployment of kernel shadow stack, that means that it needs to be supported. Thus save/restore of shadow stack pointer is implemented in entry.S instead of in 'switch_to.h'. Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-5-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv: add Zicfiss / Zicfilp extension CSR and bit definitionsDeepak Gupta
The Zicfiss and Zicfilp extensions are enabled via b3 and b2 in *envcfg CSRs. menvcfg controls enabling for S/HS mode. henvcfg controls enabling for VS. senvcfg controls enabling for U/VU mode. The Zicfilp extension extends *status CSRs to hold an 'expected landing pad' bit. A trap or interrupt can occur between an indirect jmp/call and target instruction. The 'expected landing pad' bit from the CPU is recorded into the xstatus CSR so that when the supervisor performs xret, the 'expected landing pad' state of the CPU can be restored. Zicfiss adds one new CSR, CSR_SSP, which contains the current shadow stack pointer. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-4-b55691eacf4f@rivosinc.com [pjw@kernel.org: grouped CSR_SSP macro with the other CSR macros; clarified patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv: zicfiss / zicfilp enumerationDeepak Gupta
This patch adds support for detecting the RISC-V ISA extensions Zicfiss and Zicfilp. Zicfiss and Zicfilp stand for the unprivileged integer spec extensions for shadow stack and indirect branch tracking, respectively. This patch looks for Zicfiss and Zicfilp in the device tree and accordingly lights up the corresponding bits in the cpu feature bitmap. Furthermore this patch adds detection utility functions to return whether shadow stack or landing pads are supported by the cpu. Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-3-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25dt-bindings: riscv: document zicfilp and zicfiss in extensions.yamlDeepak Gupta
Make an entry for cfi extensions in extensions.yaml. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-2-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated subject] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25mm: add VM_SHADOW_STACK definition for riscvDeepak Gupta
VM_HIGH_ARCH_5 is used for riscv. Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-1-b55691eacf4f@rivosinc.com [pjw@kernel.org: clarify subject; update to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25iommu/riscv: Simplify maximum determination in riscv_iommu_init_check()Markus Elfring
Reduce nested max() calls by a single max3() call in this function implementation. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: https://patch.msgid.link/d1a384c9-f154-4537-94d6-c3613f4167bc@web.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv: defconfig: enable NLS_ISO8859_1Javier Carrasco
NLS_ISO8859_1 was enabled as a module with commit efe1e08bca9a ("riscv: defconfig: enable NLS_CODEPAGE_437, NLS_ISO8859_1"), but the NLS_CODEPAGE_437 counterpart is selected as built-in. The commit does not explain the reason behind, and it is not consistent with the defconfig for ARM64 that also enables these modules to mount EFI system partitions. Select NLS_ISO8859_1 as built-in to provide both requirements within the kernel image. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://patch.msgid.link/20260111-nls_iso8859_1_y_riscv-v1-1-2c992bb2c00d@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv: mm: define copy_user_page() as copy_page()Florian Schmaus
Currently, the implementation of copy_user_page() is identical to copy_page(). Align riscv with other architectures (alpha, arc, arm64, hexagon, longarch, m68k, openrisc, s390, um, xtensa) and map copy_user_page() to copy_page() given that their implementation is identical. In addition to following a common pattern, this centralizes the implementation. Any changes to the underlying page copy logic (e.g., for CHERI) will now automatically propagate to copy_user_page(). Signed-off-by: Florian Schmaus <florian.schmaus@codasip.com> Link: https://patch.msgid.link/20260113134025.905627-1-florian.schmaus@codasip.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25errata/sifive: remove unreliable warn_miss_errataAndreas Schwab
When both the SiFive and MIPS errata are enabled then sifive_errata_patch_func emits a wrong and misleading warning claiming that the SiFive errata haven't been applied. This happens because sifive_errata_patch_func is being called twice, once for the kernel image and once for the vdso image. The vdso image has alternative entries for the MIPS errata, but none for the SiFive errata. Signed-off-by: Andreas Schwab <schwab@suse.de> Link: https://patch.msgid.link/mvmv7i8q8gg.fsf@suse.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv: fix minor typo in syscall.h commentAustin Kim
Some developers may be confused because RISC-V does not have a register named r0. Also, orig_r0 is not available in pt_regs structure, which is specific to riscv. So we had better fix this minor typo. Signed-off-by: Austin Kim <austin.kim@lge.com> Link: https://patch.msgid.link/aW3Z4zTBvGJpk7a7@adminpc-PowerEdge-R7525 Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25riscv: signal: fix some warnings reported by sparsePaul Walmsley
Clean up a few warnings reported by sparse in arch/riscv/kernel/signal.c. These come from code that was added recently; they were missed when I initially reviewed the patch. Fixes: 818d78ba1b3f ("riscv: signal: abstract header saving for setup_sigcontext") Cc: Andy Chiu <andybnac@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601171848.ydLTJYrz-lkp@intel.com/ [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25Linux 6.19-rc7v6.19-rc7Linus Torvalds
2026-01-25Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Only one core change, the rest are drivers. The core change reorders some state operations in the error handler to try to prevent missed wake ups of the error handler (which can halt error processing and effectively freeze the entire system)" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: qla2xxx: Sanitize payload size to prevent member overflow scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count() scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count() scsi: core: Wake up the error handler when final completions race against each other scsi: storvsc: Process unsupported MODE_SENSE_10 scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()
2026-01-25Merge tag 'keys-trusted-next-6.19-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull keys fix from Jarkko Sakkinen. * tag 'keys-trusted-next-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: keys/trusted_keys: fix handle passed to tpm_buf_append_name during unseal
2026-01-25Merge tag 'char-misc-6.19-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc/iio driver fixes from Greg KH: "Here are some small char/misc/iio and some other minor driver subsystem fixes for 6.19-rc7. Nothing huge here, just some fixes for reported issues including: - lots of little iio driver fixes - comedi driver fixes - mux driver fix - w1 driver fixes - uio driver fix - slimbus driver fixes - hwtracing bugfix - other tiny bugfixes All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (36 commits) comedi: dmm32at: serialize use of paged registers mei: trace: treat reg parameter as string uio: pci_sva: correct '-ENODEV' check logic uacce: ensure safe queue release with state management uacce: implement mremap in uacce_vm_ops to return -EPERM uacce: fix isolate sysfs check condition uacce: fix cdev handling in the cleanup path slimbus: core: clean up of_slim_get_device() slimbus: core: fix of_slim_get_device() kernel doc slimbus: core: amend slim_get_device() kernel doc slimbus: core: fix device reference leak on report present slimbus: core: fix runtime PM imbalance on report present slimbus: core: fix OF node leak on registration failure intel_th: rename error label intel_th: fix device leak on output open() comedi: Fix getting range information for subdevices 16 to 255 mux: mmio: Fix IS_ERR() vs NULL check in probe() interconnect: debugfs: initialize src_node and dst_node to empty strings iio: dac: ad3552r-hs: fix out-of-bound write in ad3552r_hs_write_data_source iio: accel: iis328dq: fix gain values ...
2026-01-25Merge tag 'tty-6.19-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull serial driver fixes from Greg KH: "Here are three small serial driver fixes for 6.19-rc7 that resolve some reported issues. They include: - tty->port race condition fix for a reported problem - qcom_geni serial driver fix - 8250_pci serial driver fix All of these have been in linux-next with no reported issues" * tag 'tty-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: Fix not set tty->port race condition serial: 8250_pci: Fix broken RS485 for F81504/508/512 serial: qcom_geni: Fix BT failure regression on RB2 platform
2026-01-25Merge tag 'i2c-for-6.19-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fix from Wolfram Sang: - k1: drop wrong IRQF_ONESHOT from IRQ request to fix genirq warning * tag 'i2c-for-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: spacemit: drop IRQF_ONESHOT flag from IRQ request
2026-01-25Merge tag 'input-for-v6.19-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - a couple of quirks to i8042 to enable keyboard on a Asus and MECHREVO laptops * tag 'input-for-v6.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: i8042 - add quirks for MECHREVO Wujie 15X Pro Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QA
2026-01-25keys/trusted_keys: fix handle passed to tpm_buf_append_name during unsealSrish Srinivasan
TPM2_Unseal[1] expects the handle of a loaded data object, and not the handle of the parent key. But the tpm2_unseal_cmd provides the parent keyhandle instead of blob_handle for the session HMAC calculation. This causes unseal to fail. Fix this by passing blob_handle to tpm_buf_append_name(). References: [1] trustedcomputinggroup.org/wp-content/uploads/ Trusted-Platform-Module-2.0-Library-Part-3-Version-184_pub.pdf Fixes: 6e9722e9a7bf ("tpm2-sessions: Fix out of range indexing in name_size") Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2026-01-24Input: i8042 - add quirks for MECHREVO Wujie 15X Progongqi
The MECHREVO Wujie 15X Pro requires several i8042 quirks to function correctly. Specifically, NOMUX, RESET_ALWAYS, NOLOOP, and NOPNP are needed to ensure the keyboard and touchpad work reliably. Signed-off-by: gongqi <550230171hxy@gmail.com> Link: https://patch.msgid.link/20260122155501.376199-3-550230171hxy@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-01-24Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QAfeng
The ASUS Zenbook UX425QA_UM425QA fails to initialize the keyboard after a cold boot. A quirk already exists for "ZenBook UX425", but some Zenbooks report "Zenbook" with a lowercase 'b'. Since DMI matching is case-sensitive, the existing quirk is not applied to these "extra special" Zenbooks. Testing confirms that this model needs the same quirks as the ZenBook UX425 variants. Signed-off-by: feng <alec.jiang@gmail.com> Link: https://patch.msgid.link/20260122013957.11184-1-alec.jiang@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-01-24Merge tag 'riscv-for-linus-6.19-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: "The notable changes here are the three RISC-V timer compare register update sequence patches. These only apply to RV32 systems and are related to the 64-bit timer compare value being split across two separate 32-bit registers. We weren't using the appropriate three-write sequence, documented in the RISC-V ISA specifications, to avoid spurious timer interrupts during the update sequence; so, these patches now use the recommended sequence. This doesn't affect 64-bit RISC-V systems, since the timer compare value fits inside a single register and can be updated with a single write. - Fix the RISC-V timer compare register update sequence on RV32 systems to use the recommended sequence in the RISC-V ISA manual This avoids spurious interrupts during updates - Add a dependence on the new CONFIG_CACHEMAINT_FOR_DMA Kconfig symbol for Renesas and StarFive RISC-V SoCs - Add a temporary workaround for a Clang compiler bug caused by using asm_goto_output for get_user() - Clarify our documentation to specifically state a particular ISA specification version for a chapter number reference" * tag 'riscv-for-linus-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Add intermediate cast to 'unsigned long' in __get_user_asm riscv: Use 64-bit variable for output in __get_user_asm soc: renesas: Fix missing dependency on new CONFIG_CACHEMAINT_FOR_DMA riscv: ERRATA_STARFIVE_JH7100: Fix missing dependency on new CONFIG_CACHEMAINT_FOR_DMA riscv: suspend: Fix stimecmp update hazard on RV32 riscv: kvm: Fix vstimecmp update hazard on RV32 riscv: clocksource: Fix stimecmp update hazard on RV32 Documentation: riscv: uabi: Clarify ISA spec version for canonical order
2026-01-24Merge tag 'ntb-6.19-bugfixes' of https://github.com/jonmason/ntbLinus Torvalds
Pull NTB fix from Jon Mason: "Bug fix for uninitialized mutex in ntb transport" * tag 'ntb-6.19-bugfixes' of https://github.com/jonmason/ntb: ntb: transport: Fix uninitialized mutex
2026-01-24Merge tag 'trace-v6.19-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Fix a crash with passing a stacktrace between synthetic events A synthetic event is an event that combines two events into a single event that can display fields from both events as well as the time delta that took place between the events. It can also pass a stacktrace from the first event so that it can be displayed by the synthetic event (this is useful to get a stacktrace of a task scheduling out when blocked and recording the time it was blocked for). A synthetic event can also connect an existing synthetic event to another event. An issue was found that if the first synthetic event had a stacktrace as one of its fields, and that stacktrace field was passed to the new synthetic event to be displayed, it would crash the kernel. This was due to the stacktrace not being saved as a stacktrace but was still marked as one. When the stacktrace was read, it would try to read an array but instead read the integer metadata of the stacktrace and dereferenced a bad value. Fix this by saving the stacktrace field as a stacktrace. - Fix possible overflow in cmp_mod_entry() compare function A binary search is used to find a module address and if the addresses are greater than 2GB apart it could lead to truncation and cause a bad search result. Use normal compares instead of a subtraction between addresses to calculate the compare value. - Fix output of entry arguments in function graph tracer Depending on the configurations enabled, the entry can be two different types that hold the argument array. The macro FGRAPH_ENTRY_ARGS() is used to find the correct arguments from the given type. One location was missed and still referenced the arguments directly via entry->args and could produce the wrong value depending on how the kernel was configured. - Fix memory leak in scripts/tracepoint-update build tool If the array fails to allocate, the memory for the values needs to be freed and was not. Free the allocated values if the array failed to allocate. * tag 'trace-v6.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: scripts/tracepoint-update: Fix memory leak in add_string() on failure function_graph: Fix args pointer mismatch in print_graph_retval() tracing: Avoid possible signed 64-bit truncation tracing: Fix crash on synthetic stacktrace field usage
2026-01-24Documentation: Project continuityDan Williams
Document project continuity procedures. This is a plan for a plan for navigating events that affect the forward progress of the canonical Linux repository, torvalds/linux.git. It is a follow-up from Maintainer Summit [1]. Co-developed-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: Jiri Kosina <jkosina@suse.com> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Link: https://lwn.net/Articles/1050179/ [1] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-01-24Merge tag 'driver-core-6.19-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Always inline I/O and IRQ methods using build_assert!() to avoid false positive build errors - Do not free the driver's device private data in I2C shutdown() avoiding race conditions that can lead to UAF bugs - Drop the driver's device private data after the driver has been fully unbound from its device to avoid UAF bugs from &Device<Bound> scopes, such as IRQ callbacks * tag 'driver-core-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: rust: driver: drop device private data post unbind rust: driver: add DriverData type to the DriverLayout trait rust: driver: add DEVICE_DRIVER_OFFSET to the DriverLayout trait rust: driver: introduce a DriverLayout trait rust: auxiliary: add Driver::unbind() callback rust: i2c: do not drop device private data on shutdown() rust: irq: always inline functions using build_assert with arguments rust: io: always inline functions using build_assert with arguments
2026-01-24Merge tag 'timers-urgent-2026-01-24' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fixes from Ingo Molnar: - Fix auxiliary timekeeper update & locking bug - Reduce the sensitivity of the clocksource watchdog, to fix false positive measurements that marked the TSC clocksource unstable * tag 'timers-urgent-2026-01-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clocksource: Reduce watchdog readout delay limit to prevent false positives timekeeping: Adjust the leap state for the correct auxiliary timekeeper
generated by cgit v1.2.3 (git 2.0.4) at 2026-09-17 19:18:42 +0000