开篇故事：一次 fork() 背后的十七个秘密

第 1 章 开篇故事：一次 fork() 背后的十七个秘密

```mermaid flowchart TD A[用户态: pid = fork] --> B[glibc 包装函数 fork] B --> C[mov eax, 57 syscall] C --> D[entry_SYSCALL_64] D --> E[do_syscall_64] E --> F[sys_call_table] F --> G[__x64_sys_fork] G --> H[__se_sys_fork] H --> I[do_fork] I --> J[copy_process] J --> K[分配 task_struct 与 PID] K --> L[复制内存、文件、信号] L --> M[wake_up_new_task] M --> N[调度器选择: 子进程先跑] N --> O[父进程返回子 PID] N --> P[子进程 ret_from_fork 返回 0] ```

如果你只读一行 C 代码就能让操作系统"凭空"克隆出一个进程——这件事本身是不是有点神奇？

```c pid_t pid = fork(); if (pid == 0) { /* 我是新生的孩子 */ } else { /* 我是父进程，pid 是孩子的编号 */ } ```

`fork()` 是 Unix 系统最古老、最奇妙的系统调用之一。它的"魔法"在于：调用一次，返回两次。但这只是表象。在用户态那一行简短的 C 代码背后，Linux 内核需要完成栈切换、寄存器保存、内存映射克隆、文件描述符表复制、调度实体初始化、信号挂起位清零等一长串操作。整个过程涉及十几个 C 文件、上百个函数，最终在不到一毫秒内完成。

很多程序员把内核当成"黑盒"——能用就好，何必深究？但本书的态度恰恰相反：内核不是不可读的怪物，它是一段段分层的代码，每一层都有清晰的边界，每一行都有它存在的理由。这一章我们就用 `fork()` 当作钥匙，把内核的门撬开一条缝，让你看到里面到底长什么样。

我们将一起回答三个核心问题：

1. Linux 内核源码到底"长"在哪里？为什么目录结构是这个样子？ 2. 一次 `fork()` 从用户态到内核态再到返回，经历了哪些函数？ 3. 有什么工具和方法，能让我们像 IDE 一样高效地阅读内核？

1.1 Linux 是宏内核：先决定我们要读什么

要读内核源码，第一件事不是下载源码，而是搞清楚它属于哪一类内核。内核的设计哲学决定了源码的组织方式。

1.1.1 宏内核 vs 微内核：架构决定目录

操作系统内核有两种主流架构：宏内核（Monolithic Kernel）和微内核（Microkernel）。

• **宏内核**把进程调度、内存管理、文件系统、设备驱动、网络协议栈等所有核心功能全部编译进同一个内核镜像，运行在内核态（Ring 0）。Linux、传统的 Unix、FreeBSD 都是宏内核。
• **微内核**只在内核态保留最基础的功能——IPC（进程间通信）、调度、极简的地址空间管理，其他服务（文件系统、网络、驱动）都运行在用户态，通过消息传递与内核通信。QNX、Minix、Fuchsia 的 zircon 部分是微内核的代表。

这两种架构对源码结构的影响是颠覆性的：

| 维度 | 宏内核 (Linux) | 微内核 (QNX/Minix) | |---|---|---| | 源码组织 | 一棵巨大的源码树，所有子系统并列 | 内核极小，服务按模块分布在用户态目录 | | 模块通信 | 直接函数调用，性能高 | 消息传递 + IPC，性能有损耗 | | 故障隔离 | 一个驱动 bug 可能拖垮整个内核 | 服务崩溃只影响自己 | | 代码量 | 6.x 内核源码接近 1 GB（解压后约 1.2 GB） | 内核通常 5–10 万行 | | 调试难度 | 中等——函数调用栈深 | 较高——消息传递路径复杂 |

Linux 走的是宏内核路线。它的源码树里，每个子目录都是一个子系统。这就是为什么你打开 https://elixir.bootlin.com 看到 Linux 的源码会感觉"目录特别多"——那不是混乱，而是因为所有东西都被塞进了同一个项目。

1.1.2 模块机制：宏内核里的"插件"

你可能会问：Linux 不是支持"可加载模块"（Loadable Kernel Module, LKM）吗？看起来像微内核的灵活性。这是个常见的误解。

模块机制是为了避免重新编译内核——你写一个 `.ko` 文件，用 `insmod` 加载，它就以内核态运行，跟其他内核代码共享同一个地址空间，可以直接调用任何导出符号（`EXPORT_SYMBOL`）。本质上，它仍然是宏内核的一种"动态加载"能力，而不是真正的进程隔离。

``` 宏内核（含模块） 微内核 ┌──────────────────┐ ┌──────────────┐ │ 进程调度 (kernel) │ │ 调度（极简） │ │ 内存管理 (mm) │ │ IPC │ │ 文件系统 (fs) │ │ 地址空间 │ │ 网络 (net) │ └──────┬───────┘ │ 驱动 (drivers) │ │ 消息 │ 模块 (drivers/*) │ ← .ko 加载 ▼ └──────────────────┘ ┌──────────────┐ 全部 Ring 0 │ 文件系统服务 │ │ 网络服务 │ │ 驱动服务 │ └──────────────┘ 用户态 ```

> 小贴士：有人把宏内核和"单内核"翻译混淆。其实宏内核（monolithic）强调的是"所有功能集中在一个二进制"，对应的是"分散在多个进程"的微内核。它并不是"没有模块"，更不是"没有结构"。

那这对我们读源码有什么影响？

因为 Linux 是宏内核，所以它的源码有以下三个特点：

1. 子系统之间没有"硬边界"。你可以从 `kernel/sched/fork.c` 直接跳转到 `mm/memory.c`，没有 IPC 跨越。这是好事——调试时调用栈是连续的，调试器能单步跟进。 2. 目录就是子系统的边界。`kernel/` 是调度和进程管理，`mm/` 是内存管理，`fs/` 是文件系统，`net/` 是网络，`drivers/` 是设备驱动，`arch/` 是架构相关代码。你只要记住目录含义，就能快速定位。 3. 体系结构代码独立。`arch/x86/`、`arch/arm64/` 等目录里的代码是不同 CPU 架构的实现差异。同一个调度算法，在 x86 和 ARM 上的中断入口、中断上下文保存细节可能完全不同；这部分被隔离到 `arch/` 目录里。

1.2 Linux 内核源码树：一张藏宝图

假设你已经通过以下命令下载了一份 Linux 6.x 内核（我们以 6.6 为例）：

```bash git clone --depth 1 --branch v6.6 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux ls ```

你会看到一堆目录和文件。最关键的几个：

| 目录 | 含义 | 我们关心的文件 | |---|---|---| | `arch/` | 各 CPU 架构的底层实现 | `arch/x86/entry/entry_64.S`（系统调用入口） | | `kernel/` | 进程、调度、信号、电源管理等核心 | `kernel/fork.c`、`kernel/sched/core.c` | | `mm/` | 内存管理 | `mm/memory.c`、`mm/mmap.c` | | `fs/` | 文件系统（VFS + 各具体 FS） | `fs/exec.c`、`fs/open.c` | | `net/` | 网络协议栈 | `net/ipv4/tcp.c` | | `drivers/` | 设备驱动（占源码 70% 以上） | `drivers/block/`、`drivers/net/` | | `include/` | 头文件，按子系统分目录 | `include/linux/sched.h`、`include/linux/mm.h` | | `init/` | 启动相关 | `init/main.c`（`start_kernel`） | | `lib/` | 通用库函数（`strcmp` 内核版等） | `lib/vsprintf.c` | | `scripts/` | 构建、配置、kconfig 解析脚本 | `scripts/kconfig/` |

1.2.1 一句话读懂每个目录

记住下面这套"读心咒"，你就能在源码树里不迷路：

• **看到 `task_struct`、`sched_entity`、`wait_queue`** → 去 `kernel/sched/` 和 `include/linux/sched.h`
• **看到 `vm_area_struct`、`page`、`mm_struct`** → 去 `mm/` 和 `include/linux/mm_types.h`
• **看到 `file`、`inode`、`dentry`、`super_block`** → 去 `fs/` 和 `include/linux/fs.h`
• **看到 `sk_buff`、`sock`、`net_device`** → 去 `net/` 和 `include/net/`
• **看到 `syscall_64`、`entry_INT80`** → 去 `arch/x86/entry/`
• **看到 `setup_arch`、`memblock`** → 去 `arch/x86/kernel/setup.c`

1.2.2 阅读源码的"三板斧"

读内核源码不能像读应用代码那样从 `main()` 一路往下——没有 `main()`。你需要三个基础工具：

第一板斧：grep

`grep` 是最朴素的，但也是最直接的。比如想知道 `fork()` 的实现：

```bash grep -rn "SYSCALL_DEFINE.*fork" kernel/ fs/ ```

它会立即告诉你，`fork()` 的定义在 `kernel/fork.c` 里。再比如：

```bash grep -rn "copy_process" kernel/ ```

你会发现这个函数被 `do_fork`、`kernel_clone`、`copy_thread` 等函数引用，调用关系一目了然。

第二板斧：ctags

`ctags` 能生成一份"符号索引"，让你在 Vim/Emacs 里按 `Ctrl+]` 跳转到函数定义：

```bash

安装

sudo apt install universal-ctags

在源码根目录生成 tags

ctags -R . ```

然后在 Vim 里打开任意文件，把光标移到 `copy_process` 上，按 `Ctrl+]`，光标会跳到 `copy_process` 的定义位置。按 `Ctrl+t` 返回。

第三板斧：cscope

`cscope` 比 ctags 更强，可以反向查找"谁调用了我"：

```bash sudo apt install cscope cscope -R ```

进入交互界面后，按 `:` 切到命令行模式，输入：

``` :find functions copy_process ```

它会列出所有调用 `copy_process` 的位置。这是理解"调用链"最关键的工具。

进阶：VSCode + clangd

如果你更喜欢 IDE 风格，可以试试 VSCode + clangd 插件：

1. 安装 `clangd` 扩展。 2. 在内核源码根目录运行 `make compile_commands.json`（需要先 `make defconfig` 或 `make allyesconfig`）。 3. 用 VSCode 打开目录，`clangd` 会自动建立索引，支持"跳转到定义"、"查找所有引用"、"鼠标悬浮看类型"。

> 经验之谈：阅读内核不要一开始就追求 IDE 全功能。刚开始用 `grep + ctags` 反而能迫使你建立完整的"调用图"心智模型。等你熟悉了，再上 IDE 才不会迷失在自动跳转里。

1.3 fork() 的十七个秘密：从用户态到内核态的完整路径

现在我们正式追踪一次 `fork()` 的旅程。为了不让数字超出预算，我把这一节组织成"十七个秘密"——每个秘密就是内核在这次调用中要做的一件事。

秘密 1：`fork()` 不是真正的系统调用，它来自 glibc

你在用户程序里写的 `fork()`，是 glibc 提供的包装函数。它长这样：

```c // glibc: sysdeps/unix/sysv/linux/fork.c pid_t fork(void) { return INLINE_SYSCALL_CALL(fork); } ```

它最终会触发一条 `syscall` 指令（在 x86_64 上），把系统调用号 57（`__NR_fork`）放进 `rax`，然后 CPU 切入内核态。

判断：理解这一点很重要——你看到的"fork 系统调用"实际上有两层：glibc 的 wrapper + 内核里的实现。两者通过 syscall ABI 对接。

秘密 2：内核入口是 `entry_SYSCALL_64`

当用户态执行 `syscall` 指令，CPU 跳转到 `arch/x86/entry/entry_64.S` 的 `_entry` 标签。汇编代码会做几件事：

1. 把用户态的寄存器全部保存到内核栈上（`pt_regs` 结构）。 2. 切换到内核栈（每个进程都有一个 `thread_info` 指向的内核栈，通常 8KB 或 16KB）。 3. 切换到内核页表（如果开启了 KPTI——Kernel Page Table Isolation）。 4. 跳到 `do_syscall_64`。

```c // arch/x86/entry/common.c __visible noinstr void do_syscall_64(struct pt_regs *regs, int nr) { add_random_kstack_offset(); instrumentation_begin();

if (!do_syscall_x64(regs, nr) && !do_syscall_x32(regs, nr)) { /* 非法系统调用处理 */ nr = array_index_nospec(nr, IA32_NR_syscalls); regs->ax = ia32_sys_call_table[nr](regs); }

instrumentation_end(); syscall_return_slowpath(regs); } ```

秘密 3：宏 `SYSCALL_DEFINE` 帮你生成系统调用实现

你在 `kernel/fork.c` 里看到的：

```c SYSCALL_DEFINE0(fork) { struct kernel_clone_args args = { .exit_signal = SIGCHLD, }; return kernel_clone(&args); } ```

这里的 `SYSCALL_DEFINE0(fork)` 是一个宏，它展开后会生成一个叫 `__x64_sys_fork` 的函数（x86_64 下），同时还会生成它的注册项。展开后大致是：

```c asmlinkage long __x64_sys_fork(const struct pt_regs *regs) { return __se_sys_fork(regs); } static inline long __se_sys_fork(const struct pt_regs *regs) { return __do_sys_fork(regs); } static inline long __do_sys_fork(const struct pt_regs *regs) { struct kernel_clone_args args = { .exit_signal = SIGCHLD, }; return kernel_clone(&args); } ```

秘密 4：`do_fork` 才是真正的 fork 实现

`__x64_sys_fork` → `kernel_clone` → `do_fork`。`do_fork` 在 5.x 版本之后实际上是个 wrapper，最终调用 `copy_process`。完整的简化链是：

```c // kernel/fork.c long kernel_clone(struct kernel_clone_args *args) { // ... 参数检查 ... p = copy_process(NULL, trace, NUMA_NO_NODE, args); if (IS_ERR(p)) return PTR_ERR(p);

// ... 唤醒新进程、wake_up_new_task ... wake_up_new_task(p);

// ...