Linux内核中内核栈与用户栈切换及中断时栈指针处理问询

Great questions—kernel stack handling is a critical, often under-explored part of how the Linux kernel manages execution context. Let’s unpack each of your questions clearly:

一、内核如何切换内核栈与用户栈？ #

First, remember that every process in Linux has two separate stacks: a user-space stack (for when it’s running in user mode) and a kernel-space stack (for when it enters kernel mode via system calls, interrupts, or exceptions).

Here’s how the switch works:

• Entering kernel mode (from user mode): When an interrupt or system call triggers a switch to kernel mode, the CPU automatically handles part of the stack switch. On x86_64, for example, the CPU will push the user-mode state (ss, rsp, rflags, cs, rip) onto the current process’s kernel stack (we’ll cover how the CPU finds this stack in the next question). After that, the kernel takes over and uses this kernel stack for all its execution while handling the interrupt/system call.
• Exiting kernel mode (back to user mode): When the kernel is done with its work, it uses instructions like iretq (for interrupts) or sysretq (for system calls) to pop the saved user-mode state off the kernel stack. This automatically restores the user-space stack pointer (rsp) and segment selector (ss), switching the CPU back to using the user stack.

For context switches between processes: When the scheduler switches to a new process, it saves the current process’s kernel stack pointer (rsp) into its task_struct (specifically the thread.sp field in the thread descriptor). Then it loads the new process’s saved kernel stack pointer into rsp, effectively switching to the new process’s kernel stack. The user stack pointer for each process is stored in the thread descriptor too, and it’s restored when the process returns to user mode.

二、中断发生时，内核是如何获取内核栈指针的？为什么没看到中断退出代码保存栈指针到寄存器？ #

Let’s split this into two parts:

1. How the kernel gets the kernel stack pointer on interrupt #

This depends on whether the interrupt hits while the CPU is in user mode or kernel mode:

• Interrupt in user mode: On architectures like x86_64, each CPU has a Task State Segment (TSS) that holds the top address of the kernel stack for the currently running process (rsp0). When the kernel switches to a process, it updates rsp0 in the TSS to point to the top of that process’s kernel stack. When an interrupt occurs in user mode, the CPU automatically loads rsp0 into the rsp register, switching to the correct kernel stack.
• Interrupt in kernel mode: If the CPU is already running in kernel mode when the interrupt hits, it’s already using a kernel stack (either the current process’s kernel stack or a per-CPU interrupt stack, depending on kernel configuration). In this case, the CPU just pushes the interrupt context onto the existing kernel stack—no need to switch stacks, so the rsp is already pointing to a valid kernel stack.

2. Why you don’t see the kernel saving the stack pointer to registers on interrupt exit #

The short answer: it doesn’t need to. Here’s why:
When an interrupt is handled, the kernel uses the kernel stack to store all the necessary context (including the state of registers from before the interrupt). When it’s time to exit the interrupt, instructions like iretq pop the saved context directly from the kernel stack back into the CPU registers.

The kernel stack pointer (rsp) itself is managed implicitly by the stack frame structure. As the interrupt handler executes, it pushes data onto the stack (increasing rsp downward, since x86 stacks grow toward lower memory). When the handler returns, it pops those values off, and rsp naturally returns to the position it was in right after the initial interrupt context was pushed. There’s no need to save rsp to a separate register because the stack’s own structure maintains this state.

Additionally, when returning to user mode, the iretq instruction pops the user-mode rsp and ss from the kernel stack, so the user stack pointer is restored directly from the stack—no extra register save is required.

内容的提问来源于stack exchange，提问作者Joontaek Oh