kernel/linux.git/Documentation/features/core, branch v7.2-rc1

LoongArch: Add THREAD_INFO_IN_TASK implementation

2026-06-25T05:03:47+00:00

Like other architectures such as x86, arm64, riscv, powerpc and s390, select THREAD_INFO_IN_TASK for LoongArch to move thread_info off the stack into task_struct. This follows modern kernel standards and also makes the system more secure. With this patch, thread_info is included in task_struct at an offset of 0 instead of being placed at the bottom of the kernel stack. Thus, the $tp register points to both thread_info and task_struct. To support this, introduce a per-CPU variable cpu_tasks to store the pointer to the current task_struct. This decouples the recovery of the $tp register from the stack pointer during exception entry. Then initialize cpu_tasks for the primary and secondary CPUs during arch-specific setup and SMP boot paths. To eliminate the dangerous windows during the early initialization where the cpu_tasks remains uninitialized, set_current() is invoked as early as possible in both setup_arch() and start_secondary(). This ensures the $tp recovery barrier is armed in case any early boot exceptions or kernel panics occur. Modify SAVE_SOME and handle_syscall to restore the $tp register from cpu_tasks, and also use the la_abs absolute addressing for cpu_tasks access in assembly to bypass the relocation limits within exception handling sections. By advancing the preservation of u0 in SAVE_SOME, we reuse the PERCPU_BASE_KS value in u0 for the cpu_tasks calculation, effectively eliminating a duplicate csrrd instruction execution on SMP platforms. Update and to fully support the CONFIG_THREAD_INFO_IN_TASK feature. Remove the obsolete next_ti argument from __switch_to(), which shifts the remaining arguments ahead in the calling convention (sched_ra from a3 to a2, and sched_cfa from a4 to a3). Under the new configuration, __switch_to() now directly derives the thread pointer ($tp) from the next task_struct pointer in a1. To preserve the optimal and clean "move tp, a1" path for 64-bit kernels, the thread pointer ($tp) is assigned directly from a1 in the core path. For 32-bit kernels, where a1 carries a 2000-byte structural pointer bias at entry, an explicit adjustment "PTR_ADDI tp, tp, -TASK_STRUCT_OFFSET" is introduced at the function exit. In the context of __switch_to(), local interrupts are disabled, and the kernel is in a critical switching phase where handling any synchronous exception is practically impossible and prohibited. If any synchronous exception or watchpoint does trigger in this narrow window, it constitutes a fatal double fault and the kernel is expected to die/panic immediately anyway. Therefore, the temporary biased value in $tp is safe and acceptable here. Additionally, evaluate the stack lookup as a single load instruction "LONG_LPTR t0, a1, (TASK_STACK - TASK_STRUCT_OFFSET)", this perfectly satisfies both 32-bit and 64-bit kernels. Using the "next" pointer in a1 as the base register, rather than $tp, effectively unchains the data dependency (RAW hazard) from the preceding move instruction, maximizing the instruction-level parallelism and superscalar execution efficiency while naturally adapting the structural shift. With CONFIG_THREAD_INFO_IN_TASK enabled, the kernel stack life cycle is decoupled from task_struct and can be freed concurrently. Currently, show_stacktrace() reads raw stack data via __get_addr() and subsequently calls show_backtrace() to unwind the frame, without holding any reference to the target task's stack. If show_stacktrace() is called on a concurrently exiting task, it could attempt to read from a freed or reallocated kernel stack. This introduces a severe use-after-free (UAF) read risk or kernel panics. Wrap the entire stack inspection process inside show_stacktrace() with a try_get_task_stack() and put_task_stack() pair. This ensures the task stack remains pinned safely during both the raw stack data dump loop and the subsequent stack unwinding phase. Also, ensure that the task pointer is initialized to "current" early if it is NULL, so that try_get_task_stack() always operates on a valid task reference. Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen

um: Add initial SMP support

2025-10-27T15:41:15+00:00

Add initial symmetric multi-processing (SMP) support to UML. With this support enabled, users can tell UML to start multiple virtual processors, each represented as a separate host thread. In UML, kthreads and normal threads (when running in kernel mode) can be scheduled and executed simultaneously on different virtual processors. However, the userspace code of normal threads still runs within their respective single-threaded stubs. That is, SMP support is currently available both within the kernel and across different processes, but still remains limited within threads of the same process in userspace. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20251027001815.1666872-6-tiwei.bie@linux.dev Signed-off-by: Johannes Berg

Merge tag 'for-linus' of https://github.com/openrisc/linux

2025-10-05T17:02:54+00:00

Pull OpenRISC updates from Stafford Horne: "I picked up one series from Chen Miao, our Google Summer of Code contributor, which adds OpenRISC support for static keys" * tag 'for-linus' of https://github.com/openrisc/linux: openrisc: Add jump label support openrisc: Regenerate defconfigs. openrisc: Add R_OR1K_32_PCREL relocation type module support openrisc: Add text patching API support

Documentation/features: Update feature lists for 6.17-rc7

2025-09-25T17:17:56+00:00

It seems that ./Documentation/features/scripts/features-refresh.sh was most recently used in December 2022, with the latest kernel release v6.1-rc7 at that time (see commit 7f2e60ff51ca ("Documentation/features: Update feature lists for 6.1") to update the feature lists in this subdirectory. All further changes to Documentation/features/ since then have probably been done manually, without checking for changes in other architectures and features, that missed to update this part of the documentation. Running ./Documentation/features/scripts/features-refresh.sh now showed seven changes of supported features in various architectures (one in arc, two in parisc, one in riscv, one in openrisc, and two in um), which were not reflected yet in the current documentation. To confirm the sanity of this script's suggested changes, I checked if the commit messages confirm that the features have in fact been added in the following commits: - commit f122668ddcce ("ARC: Add eBPF JIT support") - commit 4800a6215e33 ("parisc: Wire up eBPF JIT compiler") - commit a869b8c29f86 ("riscv: enable mseal sysmap for RV64") - commit 2f681ba4b352 ("um: move thread info into task") - commit 3f17fed21491 ("um: switch to regset API and depend on XSTATE") - commit 7ce8716e2769 ("openrisc: Add HAVE_REGS_AND_STACK_ACCESS_API support") - commit b5ff52be8913 ("parisc: Convert to generic clockevents") So, update all documents to the current state with features-refresh.sh. Signed-off-by: Lukas Bulwahn Signed-off-by: Jonathan Corbet Message-ID: <20250925073634.112142-1-lukas.bulwahn@redhat.com>

openrisc: Add jump label support

2025-09-11T10:27:59+00:00

Supported a complete jump_label implementation based on the ARM64 and RV64 version and add the CONFIG_JUMP_LABEL=y to the defconfig. Testing was conducted using a dedicated test module jump-label-test, provided in the link below. For detailed steps, please refer to the README also at the provided link. Link: https://github.com/ChenMiaoi/GSoC-2025-Final-Report/tree/main/tests/jump-label-test Test Environment: - Hardware: QEMU emulated OR1K - Kernel Version: 6.17.0-rc3-dirty - Configs: CONFIG_MODULES=y,CONFIG_MODULE_UNLOAD=y - Toolchain: or1k-none-linux-musl-gcc 15.1.0 Test Results: $ insmod jump_label_test.ko [ 32.590000] Jump label performance test module loaded [ 35.250000] Normal branch time: 1241327150 ns (124 ns per iteration) [ 35.250000] Jump label (false) time: 706422700 ns (70 ns per iteration) [ 35.250000] Jump label (true) time: 708913450 ns (70 ns per iteration) $ rmmod jump_label_test.ko [ 72.210000] Jump label test module unloaded The results show approximately 43% improvement in branch performance when using jump labels compared to traditional branches. Link: https://lore.kernel.org/openrisc/aLsZ9S3X0OpKy1RM@antec/T/#u Signed-off-by: chenmiao Signed-off-by: Stafford Horne

LoongArch: Enable ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS

2025-05-30T13:45:42+00:00

Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on LoongArch, covering the vdso. Link: https://lore.kernel.org/all/25bad37f-273e-4626-999c-e1890be96182@lucifer.local/ Acked-by: Liam R. Howlett Acked-by: Lorenzo Stoakes Reviewed-by: Jeff Xu Tested-by: Yuli Wang Signed-off-by: Yuli Wang Signed-off-by: Huacai Chen

mseal sysmap: add arch-support txt

2025-04-01T22:17:17+00:00

Add Documentation/features/core/mseal_sys_mappings/arch-support.txt N/A: the arch is 32bits only and mseal is not supported in 32 bits, therefore N/A (until mseal is available in 32 bits kernel). [jeffxu@chromium.org: update to v3] Link: https://lkml.kernel.org/r/20250324151537.1106542-2-jeffxu@google.com Link: https://lkml.kernel.org/r/20250321032627.4147562-2-jeffxu@google.com Signed-off-by: Jeff Xu Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Eric Dumaze Cc: Geert Uytterhoeven Cc: guoweikang Cc: Heiko Carstens Cc: Kevin Brodsky Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Meghana Malladi Cc: Qi Zheng Cc: Sven Schnelle Cc: Thomas Weißschuh Cc: Vasily Gorbik Signed-off-by: Andrew Morton

Documentation: Drop IA64 from feature descriptions

2023-09-11T08:13:18+00:00

Itanium (IA64) is going away, so drop it from the kernel feature documentation. Signed-off-by: Ard Biesheuvel

Documentation: Fix typos

2023-08-18T17:29:03+00:00

Fix typos in Documentation. Signed-off-by: Bjorn Helgaas Link: https://lore.kernel.org/r/20230814212822.193684-4-helgaas@kernel.org Signed-off-by: Jonathan Corbet

LoongArch: Add jump-label implementation

2023-06-29T12:58:44+00:00

Add support for jump labels based on the ARM64 version. Acked-by: Peter Zijlstra (Intel) Signed-off-by: Youling Tang Signed-off-by: Huacai Chen