summaryrefslogtreecommitdiff
path: root/Documentation/features/core/thread-info-in-task
AgeCommit message (Collapse)Author
2026-06-25LoongArch: Add THREAD_INFO_IN_TASK implementationTiezhu Yang
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 <asm/switch_to.h> and <kernel/switch.S> 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 <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-09-25Documentation/features: Update feature lists for 6.17-rc7Lukas Bulwahn
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 <lukas.bulwahn@redhat.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20250925073634.112142-1-lukas.bulwahn@redhat.com>
2023-09-11Documentation: Drop IA64 from feature descriptionsArd Biesheuvel
Itanium (IA64) is going away, so drop it from the kernel feature documentation. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-08-18Documentation: Fix typosBjorn Helgaas
Fix typos in Documentation. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20230814212822.193684-4-helgaas@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-12-05Documentation/features: Use loongarch instead of loongTiezhu Yang
The official arch name is LoongArch [1], we should use small letter loongarch instead of loong in Documentation/features, just use the features-refresh.sh to refresh all the related files. [1] https://www.kernel.org/doc/html/latest/loongarch/index.html Fixes: 5860800e8696 ("Documentation/features: Update the arch support status files") Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Link: https://lore.kernel.org/r/1670156327-9631-3-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-06-09Documentation/features: Update the arch support status filesZheng Zengkai
The arch support status files don't match reality as of v5.19-rc1, use the features-refresh.sh to refresh all the arch-support.txt files in place. The main effect is to add entries for the new loong architecture. Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> Link: https://lore.kernel.org/r/20220609025656.143460-1-zhengzengkai@huawei.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-04-04Merge branch 'remove-h8300' of git://git.infradead.org/users/hch/misc into ↵Arnd Bergmann
asm-generic * 'remove-h8300' of git://git.infradead.org/users/hch/misc: remove the h8300 architecture This is clearly the least actively maintained architecture we have at the moment, and probably the least useful. It is now the only one that does not support MMUs at all, and most of the boards only support 4MB of RAM, out of which the defconfig kernel needs more than half just for .text/.data. Guenter Roeck did the original patch to remove the architecture in 2013 after it had already been obsolete for a while, and Yoshinori Sato brought it back in a much more modern form in 2015. Looking at the git history since the reinstantiation, it's clear that almost all commits in the tree are build fixes or cross-architecture cleanups: $ git log --no-merges --format=%an v4.5.. arch/h8300/ | sort | uniq -c | sort -rn | head -n 12 25 Masahiro Yamada 18 Christoph Hellwig 14 Mike Rapoport 9 Arnd Bergmann 8 Mark Rutland 7 Peter Zijlstra 6 Kees Cook 6 Ingo Molnar 6 Al Viro 5 Randy Dunlap 4 Yury Norov Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-07nds32: Remove the architectureAlan Kao
The nds32 architecture, also known as AndeStar V3, is a custom 32-bit RISC target designed by Andes Technologies. Support was added to the kernel in 2016 as the replacement RISC-V based V5 processors were already announced, and maintained by (current or former) Andes employees. As explained by Alan Kao, new customers are now all using RISC-V, and all known nds32 users are already on longterm stable kernels provided by Andes, with no development work going into mainline support any more. While the port is still in a reasonably good shape, it only gets worse over time without active maintainers, so it seems best to remove it before it becomes unusable. As always, if it turns out that there are mainline users after all, and they volunteer to maintain the port in the future, the removal can be reverted. Link: https://lore.kernel.org/linux-mm/YhdWNLUhk+x9RAzU@yamatobi.andestech.com/ Link: https://lore.kernel.org/lkml/20220302065213.82702-1-alankao@andestech.com/ Link: https://www.andestech.com/en/products-solutions/andestar-architecture/ Signed-off-by: Alan Kao <alankao@andestech.com> [arnd: rewrite changelog to provide more background] Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-02-23remove the h8300 architectureChristoph Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-12-17ARM: 9158/1: leave it to core code to manage thread_info::cpuArd Biesheuvel
Since commit bcf9033e5449 ("sched: move CPU field back into thread_info if THREAD_INFO_IN_TASK=y"), the CPU field in thread_info went back to being managed by the core code, so we no longer have to keep it in sync in arch code. While at it, mark THREAD_INFO_IN_TASK as done for ARM in the documentation. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-11-01parisc: Move thread_info into task structHelge Deller
This implements the CONFIG_THREAD_INFO_IN_TASK option. With this change: - before thread_info was part of the stack and located at the beginning of the stack - now the thread_info struct is moved and located inside the task_struct structure - the stack is allocated and handled like the major other platforms - drop the cpu field of thread_info and use instead the one in task_struct Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sven Schnelle <svens@stackframe.org>
2021-07-15Documentation/features: Add THREAD_INFO_IN_TASK feature matrixIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/YN2nhV5F0hBVNPuX@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>