kernel/linux.git/arch/loongarch/include/asm/stackframe.h, branch v7.2-rc2

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

LoongArch: Adjust common macro definitions for 32BIT/64BIT

2025-12-06T02:40:32+00:00

Most common macros are defined in asm.h, asmmacro.h and stackframe.h. Adjust these macros for both 32BIT and 64BIT. Add SETUP_TWINS (Setup Trampoline Windows) and SETUP_MODES (Setup CRMD/ PRMD/EUEN) which will be used later. Reviewed-by: Arnd Bergmann Signed-off-by: Jiaxun Yang Signed-off-by: Huacai Chen

LoongArch: Rename GCC_PLUGIN_STACKLEAK to KSTACK_ERASE

2025-08-20T14:23:44+00:00

Commit 57fbad15c2eee772 ("stackleak: Rename STACKLEAK to KSTACK_ERASE") misses the stackframe.h part for LoongArch, so fix it. Fixes: 57fbad15c2eee772 ("stackleak: Rename STACKLEAK to KSTACK_ERASE") Signed-off-by: Huacai Chen

LoongArch: Enable HAVE_ARCH_STACKLEAK

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

Add support for the stackleak feature. It initializes the stack with the poison value before returning from system calls which improves the kernel security. At the same time, disables the plugin in EFI stub code because EFI stub is out of scope for the protection. Tested on Loongson-3A5000 (enable GCC_PLUGIN_STACKLEAK and LKDTM): # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT # dmesg lkdtm: Performing direct entry STACKLEAK_ERASING lkdtm: stackleak stack usage: high offset: 320 bytes current: 448 bytes lowest: 1264 bytes tracked: 1264 bytes untracked: 208 bytes poisoned: 14528 bytes low offset: 64 bytes lkdtm: OK: the rest of the thread stack is properly erased Signed-off-by: Youling Tang Signed-off-by: Huacai Chen

LoongArch: Add writecombine support for DMW-based ioremap()

2024-07-20T14:40:59+00:00

Currently, only TLB-based ioremap() support writecombine, so add the counterpart for DMW-based ioremap() with help of DMW2. The base address (WRITECOMBINE_BASE) is configured as 0xa000000000000000. DMW3 is unused by kernel now, however firmware may leave garbage in them and interfere kernel's address mapping. So clear it as necessary. BTW, centralize the DMW configuration to macro SETUP_DMWINS. Signed-off-by: Jiaxun Yang Signed-off-by: Huacai Chen

LoongArch: Override higher address bits in JUMP_VIRT_ADDR

2024-06-03T07:45:53+00:00

In JUMP_VIRT_ADDR we are performing an or calculation on address value directly from pcaddi. This will only work if we are currently running from direct 1:1 mapping addresses or firmware's DMW is configured exactly same as kernel. Still, we should not rely on such assumption. Fix by overriding higher bits in address comes from pcaddi, so we can get rid of or operator. Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang Signed-off-by: Huacai Chen

LoongArch: Add ORC stack unwinder support

2024-03-11T14:23:47+00:00

The kernel CONFIG_UNWINDER_ORC option enables the ORC unwinder, which is similar in concept to a DWARF unwinder. The difference is that the format of the ORC data is much simpler than DWARF, which in turn allows the ORC unwinder to be much simpler and faster. The ORC data consists of unwind tables which are generated by objtool. After analyzing all the code paths of a .o file, it determines information about the stack state at each instruction address in the file and outputs that information to the .orc_unwind and .orc_unwind_ip sections. The per-object ORC sections are combined at link time and are sorted and post-processed at boot time. The unwinder uses the resulting data to correlate instruction addresses with their stack states at run time. Most of the logic are similar with x86, in order to get ra info before ra is saved into stack, add ra_reg and ra_offset into orc_entry. At the same time, modify some arch-specific code to silence the objtool warnings. Co-developed-by: Jinyang He Signed-off-by: Jinyang He Co-developed-by: Youling Tang Signed-off-by: Youling Tang Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen

LoongArch: Add basic KGDB & KDB support

2023-09-06T14:53:55+00:00

KGDB is intended to be used as a source level debugger for the Linux kernel. It is used along with gdb to debug a Linux kernel. GDB can be used to "break in" to the kernel to inspect memory, variables and regs similar to the way an application developer would use GDB to debug an application. KDB is a frontend of KGDB which is similar to GDB. By now, in addition to the generic KGDB features, the LoongArch KGDB implements the following features: - Hardware breakpoints/watchpoints; - Software single-step support for KDB. Signed-off-by: Qing Zhang # Framework & CoreFeature Signed-off-by: Binbin Zhou # BreakPoint & SingleStep Signed-off-by: Hui Li # Some Minor Improvements Signed-off-by: Randy Dunlap # Some Build Error Fixes Signed-off-by: Huacai Chen

LoongArch: Add la_abs macro implementation

2023-02-25T14:12:16+00:00

Use the "la_abs macro" instead of the "la.abs pseudo instruction" to prepare for the subsequent PIE kernel. When PIE is not enabled, la_abs is equivalent to la.abs. Signed-off-by: Youling Tang Signed-off-by: Huacai Chen

LoongArch: Add JUMP_VIRT_ADDR macro implementation to avoid using la.abs

2023-02-25T14:12:16+00:00

Add JUMP_VIRT_ADDR macro implementation to avoid using la.abs directly. This is a preparation for subsequent patches. Signed-off-by: Youling Tang Signed-off-by: Huacai Chen