调试一个内核崩溃的时候盯着 dmesg 里的 Call Trace 看了很久，栈回溯里既有用户态的函数，又有内核态的一长串 entry_SYSCALL_64、do_syscall_64、ksys_read。当时冒出一个问题：一次 read() 系统调用，进内核前用的是哪个栈，进内核后又切到哪个栈，那些寄存器参数到底存在哪里。
把这条链路捋清楚，很多内核数据结构就串起来了。这篇从用户栈讲到内核栈，看一次系统调用里数据是怎么摆放的。
用户栈：一次普通函数调用的样子
先看用户态。程序调 read() 的时候，走的是 glibc 的包装函数，这一步跟调任何普通 C 函数没区别，用的是线程自己的用户栈。
x86-64 的栈从高地址往低地址生长。调用一个函数时，栈上大致是这样：
高地址
┌──────────────────┐
│ caller 的局部变量 │
├──────────────────┤
│ read() 的返回地址 │ ← call 指令自动压入
├──────────────────┤
│ 保存的 RBP │ ← 函数开头 push %rbp
├──────────────────┤
│ read() 局部变量 │ ← RSP 指向这里
└──────────────────┘
低地址
这里有个容易搞混的点：x86-64 的调用约定（System V ABI）里，前六个整型参数是通过寄存器传的，不走栈。read(fd, buf, count) 三个参数分别放在 RDI、RSI、RDX。所以用户栈上通常看不到这几个参数，它们一直待在寄存器里，直到进内核。
glibc 的 read 包装函数很薄，核心就是把参数摆进指定寄存器，然后执行 syscall 指令：
mov $0, %eax ; 系统调用号 __NR_read = 0
syscall ; 陷入内核
ret
注意系统调用号放在 RAX。read 是 0，write 是 1，openat 是 257。执行 syscall 之前，寄存器的分工是这样：
RAX = 系统调用号
RDI = 参数1 (fd)
RSI = 参数2 (buf)
RDX = 参数3 (count)
R10 = 参数4 ← 注意不是 RCX
R8 = 参数5
R9 = 参数6
第四个参数用 R10 而不是普通函数调用约定里的 RCX，是因为 syscall 指令本身要占用 RCX。这是系统调用约定和函数调用约定唯一不一样的地方。
syscall 指令做了什么
syscall 不是简单的跳转。这条指令是硬件专门为系统调用设计的，一条指令干了好几件事：
第一，把当前的 RIP（也就是 syscall 下一条指令 ret 的地址）存进 RCX。第二，把 RFLAGS 存进 R11。第三，从 MSR_LSTAR 这个寄存器里取出内核入口地址，加载到 RIP。这个入口就是 entry_SYSCALL_64。
所以 syscall 执行完，CPU 已经跳到内核代码了，但此时有个尴尬的状态：RSP 还指着用户栈。内核代码绝对不能用用户栈干活，用户栈的内容用户态可以随便改，用它会造成严重安全问题。所以进内核后第一件事就是换栈。
内核栈从哪来
每个线程除了用户栈，还有一个独立的内核栈。这个栈在线程创建时就分配好了，大小是 THREAD_SIZE。x86-64 上这个值是 16KB：
// arch/x86/include/asm/page_64_types.h
#define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER)
#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
PAGE_SIZE 是 4KB，THREAD_SIZE_ORDER 在不开 KASAN 时是 2，也就是 4 个页，16KB。早期内核是 8KB，2014 年之后为了应付越来越深的调用链改成了 16KB。
问题是内核怎么在 syscall 之后立刻找到这个栈。答案是 per-cpu 变量。每个 CPU 都记着当前正在运行的线程的内核栈顶地址，entry_SYSCALL_64 一进来就从 per-cpu 区域把这个地址捞出来赋给 RSP：
SYM_CODE_START(entry_SYSCALL_64)
swapgs ; 切换到内核 GS
movq %rsp, PER_CPU_VAR(cpu_tss_rw + TSS_sp2) ; 暂存用户栈指针
movq PER_CPU_VAR(pcpu_hot + X86_top_of_stack), %rsp ; 换成内核栈顶
...
swapgs 是配套的一步。用户态和内核态各有一个 GS 基址，swapgs 把它们对调，这样内核就能通过 GS 访问 per-cpu 数据。用户栈指针先暂存到 TSS 的一个字段里，等下要用。
内核栈上的 pt_regs
换到内核栈之后，内核要干的第一件正事是把用户态的寄存器现场全部保存下来。因为内核代码马上要用这些寄存器干自己的活，用完之后还得原样恢复给用户态。这个现场保存的结构就是 pt_regs。
entry_SYSCALL_64 后面一段就是手工构造 pt_regs，一路 push：
pushq $__USER_DS ; pt_regs->ss
pushq PER_CPU_VAR(cpu_tss_rw + TSS_sp2) ; pt_regs->sp（刚才暂存的用户栈）
pushq %r11 ; pt_regs->flags（syscall 存进来的 RFLAGS）
pushq $__USER_CS ; pt_regs->cs
pushq %rcx ; pt_regs->ip（syscall 存进来的返回地址）
pushq %rax ; pt_regs->orig_ax（系统调用号）
PUSH_AND_CLEAR_REGS rax=$-ENOSYS ; 保存其余通用寄存器
push 完之后，内核栈顶就是一个完整的 pt_regs 结构。它的定义是这样：
// arch/x86/include/asm/ptrace.h
struct pt_regs {
unsigned long r15;
unsigned long r14;
unsigned long r13;
unsigned long r12;
unsigned long bp;
unsigned long bx;
unsigned long r11;
unsigned long r10;
unsigned long r9;
unsigned long r8;
unsigned long ax;
unsigned long cx;
unsigned long dx;
unsigned long si;
unsigned long di;
unsigned long orig_ax;
/* 下面这五个是 iretq 返回用户态需要的帧 */
unsigned long ip;
unsigned long cs;
unsigned long flags;
unsigned long sp;
unsigned long ss;
};
结构体成员的顺序和汇编里 push 的顺序是反过来的。因为栈往低地址生长，最后 push 的 r15 在最低地址，也就是结构体的第一个成员；最先 push 的 ss 在最高地址，是结构体最后一个成员。内核后面用 C 代码访问 pt_regs 时，就是靠这个精确对应的顺序把每个寄存器读出来的。
整个内核栈的布局是这样：
高地址（栈底，THREAD_SIZE 顶端）
┌──────────────────┐
│ pt_regs (ss) │ ← 用户态寄存器现场
│ pt_regs (sp) │
│ ... │
│ pt_regs (r15) │ ← RSP 进 do_syscall_64 时指向这里
├──────────────────┤
│ do_syscall_64 帧 │
├──────────────────┤
│ ksys_read 帧 │
├──────────────────┤
│ vfs_read 帧 │ ← 内核调用越深，栈往低地址长
│ ... │
└──────────────────┘
低地址（栈顶，接近这里就是栈溢出）
do_syscall_64 拿到的第一个参数就是 pt_regs 指针。汇编里 movq %rsp, %rdi 把栈顶地址传给它，C 代码里就能直接读 regs->di、regs->si 拿到用户传进来的参数：
// arch/x86/entry/common.c
__visible noinstr void do_syscall_64(struct pt_regs *regs, int nr)
{
...
if (likely(do_syscall_x64(regs, nr)))
goto done;
...
}
thread_info 不在栈底了
如果你看的是老资料，会说内核栈的最低地址处放着一个 thread_info 结构，current 宏靠把栈指针的低位抹掉就能找到它。这个说法在现在的 x86-64 内核上已经不对了。
从 4.9 开始，内核引入了 CONFIG_THREAD_INFO_IN_TASK，把 thread_info 直接塞进了 task_struct 里，不再单独放在栈底。这么改是为了安全：thread_info 放栈底，一旦发生栈溢出就会把它冲掉，而 thread_info 里有权限相关字段，被踩了很危险。
对应地，current 宏现在也不靠栈指针推算了，而是直接读 per-cpu 变量：
// arch/x86/include/asm/current.h
static __always_inline struct task_struct *get_current(void)
{
return this_cpu_read_stable(pcpu_hot.current_task);
}
#define current get_current()
想从 task_struct 反过来拿它的 pt_regs，用 task_pt_regs 宏，它算的就是内核栈顶那块：
// arch/x86/include/asm/processor.h
#define task_pt_regs(task) \
({ unsigned long __ptr = (unsigned long)task_stack_page(task); \
__ptr += THREAD_SIZE - TOP_OF_KERNEL_STACK_PADDING; \
((struct pt_regs *)__ptr) - 1; })
先拿到栈的基址，加上 THREAD_SIZE 到栈顶，再往回退一个 pt_regs 的大小，正好落在 pt_regs 的起始位置。
栈溢出会怎样
内核栈只有 16KB，而且不像用户栈能自动增长，它就是固定这么大。内核里递归太深、或者某个函数在栈上开了个巨大的数组，就可能冲破这 16KB。
老内核对这种溢出几乎没有防护，栈往下越界会直接踩到相邻的内存，通常是另一个线程的 thread_info 或者别的内核数据，然后系统以各种诡异的方式崩溃，还很难查。
现在有了 CONFIG_VMAP_STACK。开启后内核栈从 vmalloc 区域分配，栈的下方紧挨着一个 guard page（保护页），这个页没有映射。一旦栈访问越界踩到 guard page，会立刻触发缺页异常，内核马上报一个明确的 stack guard page 错误并 panic，而不是默默地破坏数据。这让栈溢出从一个隐蔽的疑难杂症变成了当场就能定位的问题。
返回用户态
系统调用干完活，内核要沿原路返回。do_syscall_64 的返回值会写进 pt_regs->ax，这就是 read() 最终的返回值。然后走 syscall 的返回路径，把 pt_regs 里保存的寄存器全部弹回来，最后用 sysret 指令，从 RCX 恢复 RIP、从 R11 恢复 RFLAGS，栈指针切回用户栈，CPU 又回到用户态那条 syscall 之后的 ret 指令。
整条链路的栈切换其实就两次：进内核时从用户栈换到内核栈，出内核时再换回来。用户栈存的是 glibc 包装函数的调用帧，内核栈存的是用户寄存器现场（pt_regs）加上内核函数的调用帧。中间靠 pt_regs 这一个结构把用户态的现场完整地带过来又带回去。
搞清楚这条链路之后再看内核崩溃的 Call Trace，就知道每一层栈帧对应的是哪个栈、哪个阶段，排查起来清楚多了。
