3.4 进程描述与创建

3.3 讲了怎么进入内核。现在问：进来之后，内核怎么知道「当前是谁」？current 这个宏从哪里取到指针？一个进程和另一个进程共享哪些东西、独享哪些东西？

进程是内核里最复杂的一个对象。Linux 的 task_struct 把「执行流」与「资源」揉在一起，再用一组 CLONE_* 标志决定 fork 时哪些资源共享、哪些复制——线程不过是「共享得更多的进程」。理解了这套标志，fork/vfork/clone/pthread_create/容器里的 PID 1 就都能用同一张图解释。

本章顺序：先看对象（task_struct、内核栈、current），再看共享规则（CLONE_* 与 pid/tgid），然后走 kernel_clone() → copy_process() 的创建路径、COW 的触发点、do_exit() 的退出路径，最后用两个实验把「共享」与「复制」的差别测出来。母本对照：奔跑吧 3.1（进程的诞生）、李治军第 3 章（多进程）、Kerrisk 第 24–27 章（用户态接口）。

3.4.1 task_struct：9 KiB 里的全部状态

字段太多，按「指向什么」分组记：

                       ┌──────────────────────────────┐
                       │        task_struct           │
                       ├──────────────────────────────┤
 调度 ─────────────────┤ __state  prio  static_prio   │
                       │ policy   cpus_ptr  mems_allowed
                       │ se (sched_entity)  rt  dl     │
 身份 ─────────────────┤ pid  tgid  comm[TASK_COMM_LEN]│
                       │ cred  *real_cred  *cred       │
 地址空间 ─────────────┤ mm  ───────────► mm_struct   │
                       │ active_mm（内核线程借用）     │
 文件 ─────────────────┤ files ─────────► files_struct│
                       │ fs ────────────► fs_struct   │
 命名空间 ─────────────┤ nsproxy ───────► nsproxy     │
 信号 ─────────────────┤ signal  sighand  blocked     │
 执行 ─────────────────┤ stack（内核栈基址）           │
                       │ thread（thread_struct：sp/ip/fsbase）
                       │ thread_info（嵌入在结构体头部）│
                       └──────────────────────────────┘

几个容易记混的点：

• __state 不是 state。6.x 里字段名是 __state，配套宏 task_is_running()、READ_ONCE(p->__state)。直接读 p->state 在 5.14 之后编译不过。
• pid 与 tgid：pid 是内核给这个 task 的唯一号（线程各有各的），tgid 是线程组号（等于主线程的 pid）。用户态 getpid() 返回的是 tgid，gettid() 返回 pid。
• mm 与 active_mm：用户进程的 mm 非空；内核线程 mm == NULL，借用上一个用户进程的 active_mm，避免每次切换都换页表（lazy TLB）。
• thread_info 嵌在 task_struct 头部（CONFIG_THREAD_INFO_IN_TASK），不再是内核栈的起点。所以「栈溢出踩到 thread_info」这种老故事在 6.8 上不成立，栈溢出会直接踩到相邻内存或 guard page。

内核栈只有 16 KiB，这是个硬约束：任何在栈上放大数组（char buf[8192]）的代码都在赌命。内核有 CONFIG_DEBUG_STACK_USAGE 与 check_stack_usage() 统计每个任务用过的最大栈深，/proc/PID/stack 能看到内核栈上的调用链（需要 CONFIG_STACKTRACE 与 root）。

3.4.2 进程与线程：只差一组标志

Linux 不区分「进程」与「线程」两种对象，只有 task。区别在于创建时共享了哪些资源：

pthread_create() 最终调用的是：

clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND |
      CLONE_THREAD | CLONE_SYSVSEM | CLONE_SETTLS |
      CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID, ...);

CLONE_THREAD 是「成为线程」的关键：它让新 task 与调用者同属一个线程组，共享 tgid，并且不产生新的 SIGCHLD——线程退出不会通知父进程，只有组内最后一个线程退出时才会。CLONE_CHILD_CLEARTID 配合 futex 实现 pthread_join() 的等待：线程退出时内核把 tid 清零并唤醒等在 futex 上的 joiner。

pid 的组织方式也随之分层。struct pid 不直接存一个整数，而是存「在每个命名空间里的编号」：

/* include/linux/pid.h —— 6.8 节选 */
struct pid {
	refcount_t count;
	unsigned int level;              /* 所在命名空间的层数 */
	spinlock_t lock;
	struct hlist_head tasks[PIDTYPE_MAX];   /* PID/PGID/SID/TGID 四种用途 */
	struct rcu_head rcu;
	struct upid numbers[];           /* 每层一个编号 */
};

struct upid {
	int nr;                          /* 在该命名空间里的数值 */
	struct pid_namespace *ns;
};

同一个进程在宿主命名空间里是 12345，在容器里可能是 1。pid_nr_ns(pid, ns) 按命名空间取对应的 nr，task_pid_nr() 取初始命名空间的值。这也解释了为什么容器里的 PID 1 在宿主上只是普通进程。

3.4.3 创建：kernel_clone 与 copy_process

所有创建路径——fork()、vfork()、clone()、clone3()、pthread_create()、kernel_thread()——最终都进 kernel/fork.c: kernel_clone()：

/* kernel/fork.c: kernel_clone() —— 6.8 节选，已简化 */
pid_t kernel_clone(struct kernel_clone_args *args)
{
	u64 clone_flags = args->flags;
	struct completion vfork;
	struct pid *pid;
	struct task_struct *p;
	int trace = 0;
	pid_t nr;

	if ((clone_flags & (CLONE_NEWUSER | CLONE_FS)) == (CLONE_NEWUSER | CLONE_FS))
		return -EINVAL;
	...
	p = copy_process(NULL, trace, NUMA_NO_NODE, args);
	if (IS_ERR(p))
		return PTR_ERR(p);

	pid = get_task_pid(p, PIDTYPE_PID);
	nr = pid_vnr(pid);
	...
	wake_up_new_task(p);
	...
	return nr;
}

copy_process() 是真正的重头戏，顺序不能乱：

/* kernel/fork.c: copy_process() —— 6.8 节选，省略错误处理 */
	retval = dup_task_struct(current, node);   /* task_struct + 内核栈 */
	retval = copy_creds(p, clone_flags);       /* 凭据（COW 或复制） */
	retval = sched_fork(clone_flags, p);       /* 调度器初始化，状态 TASK_NEW */
	retval = copy_files(clone_flags, p);       /* fd 表 */
	retval = copy_fs(clone_flags, p);          /* cwd/root */
	retval = copy_sighand(clone_flags, p);     /* 信号处理函数表 */
	retval = copy_signal(clone_flags, p);      /* 信号队列与统计 */
	retval = copy_mm(clone_flags, p);          /* 地址空间 → dup_mm() */
	retval = copy_namespaces(clone_flags, p);  /* 命名空间 */
	retval = copy_io(clone_flags, p);          /* io_context（AIO/io_uring） */
	retval = copy_thread(p, args);             /* 寄存器与栈，返回地址 ret_from_fork */
	pid = alloc_pid(p->nsproxy->pid_ns_for_children, args->set_tid, args->set_tid_size);
	...
	wake_up_new_task(p);                       /* 入队，可能抢占当前 */

每一步都能单独写一章，这里只抓三条主线：

1. dup_task_struct() 复制的是「描述」，不是「内存」。它分配一个新的 task_struct，把父进程的字段整体拷过来，再分配一个新的内核栈，把父进程的 pt_regs 复制到栈顶——子进程从 ret_from_fork 开始执行，fork() 在用户态返回 0 就是这么来的。
2. copy_mm() 只复制页表，不复制物理页。它调用 dup_mm() → dup_mmap()，遍历父进程的每个 VMA，复制 VMA 结构，复制页表项，并把两边的 PTE 都改成只读。物理页的引用计数加一。这就是 COW（copy-on-write）。
3. alloc_pid() 分配的是 struct pid 与各层编号。idr_alloc_cyclic() 在 pid_namespace->idr 里找一个空号，默认上限 pid_max = 32768（systemd 常调到 4194304）。号用完不会立即复用，pid_max 越大越不容易回绕。

三种用户态入口的差别：

vfork() 的历史价值是「不复制页表」，在 fork 昂贵的年代很快；今天 fork + COW 已经足够快，vfork 的共享地址空间反而危险（子进程改一个变量会直接影响父进程），新代码应优先 posix_spawn() 或 clone3()。

3.4.4 COW：fork 快的真正原因

读图：fork 之后子进程进入 TASK_RUNNING（就绪队列），退出时先到 TASK_ZOMBIE，等父进程 wait() 才到 EXIT_DEAD。图里没有画 COW，但它是「就绪」之前发生的事。

内核侧的两个关键函数：

/* mm/memory.c: copy_present_pte() —— 6.8 节选，已简化 */
static inline void copy_present_pte(struct vm_area_struct *dst_vma,
				    struct vm_area_struct *src_vma,
				    pte_t *dst_pte, pte_t *src_pte,
				    pte_t pte, unsigned long addr)
{
	struct page *page = vm_normal_page(src_vma, addr, pte);

	if (page)
		get_page(page);                  /* 引用计数 +1，两边共享 */
	...
	pte = pte_wrprotect(pte);                /* 两边都改成只读 */
	pte = pte_mkold(pte);
	set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte);
}

写侧的入口是缺页异常：

/* mm/memory.c: do_wp_page() —— 6.8 节选，已简化 */
vm_fault_t do_wp_page(struct vm_fault *vmf)
{
	struct folio *folio = page_folio(vmf->page);

	if (unlikely(folio_test_ksm(folio)))
		return wp_page_copy(vmf);        /* KSM 页必须复制 */
	...
	if (folio_ref_count(folio) + folio_mapcount(folio) == 2 &&
	    !folio_test_swapcache(folio)) {
		/* 只有当前映射，独占：直接复用，不必复制 */
		folio_make_writable(folio);
		...
		return 0;
	}
	return wp_page_copy(vmf);            /* 共享：分配新页并复制 */
}

代价要算清楚：

• fork() 的成本 = 复制页表 + 复制 VMA + 复制 task_struct。与进程的虚拟内存大小成正比，与 RSS 关系不大。一个映射了 10 GiB 但只碰了几页的进程，fork 要复制几万个 PTE，仍然慢。
• 第一次写每一页的成本 = 一次缺页 + 一次 4 KiB 复制。写 1 GiB 匿名内存，等于 26 万次缺页。
• fork 之后立刻 exec 是最常见的组合，此时 COW 的复制全部白做。posix_spawn()/vfork() 就是为这个场景优化的。

3.4.5 新进程什么时候开始跑

copy_process() 返回时，新 task 已经完整，但还没被调度。它的 __state 是 TASK_NEW，不在任何运行队列里。wake_up_new_task() 做三件事：

1. p->__state = TASK_RUNNING；
2. activate_task(rq, p, ENQUEUE_WAKEUP) 把 sched_entity 插入运行队列（EEVDF 下是红黑树，按 deadline 排序）；
3. check_preempt_curr(rq, p, WF_FORK) 判断是否该抢占当前进程。

第 3 步是「子进程可能先于父进程运行」的原因：如果新进程的权重更高、或者父进程的切片已用完，resched_curr() 会置 TIF_NEED_RESCHED，父进程从 fork() 返回后不久就被抢占。

copy_thread() 决定了子进程从哪里开始执行：

/* arch/x86/kernel/process.c: copy_thread() —— 6.8 节选，已简化 */
int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
{
	unsigned long clone_flags = args->flags;
	struct inactive_task_frame *frame;
	struct fork_frame *fork_frame;
	struct pt_regs *childregs;

	childregs = task_pt_regs(p);
	fork_frame = container_of(childregs, struct fork_frame, regs);
	frame = &fork_frame->frame;

	frame->bp = encode_frame_pointer(childregs);
	frame->ret_addr = (unsigned long) ret_from_fork_asm;
	p->thread.sp = (unsigned long) fork_frame;
	p->thread.io_bitmap = NULL;
	...
	if (unlikely(p->flags & PF_KTHREAD)) {
		/* 内核线程：从 kthread 函数开始，不返回用户态 */
		p->thread.pkru = 0;
		memset(childregs, 0, sizeof(struct pt_regs));
		frame->bx = (unsigned long) args->fn;
		frame->r12 = (unsigned long) args->fn_arg;
	} else {
		*childregs = *current_pt_regs();
		childregs->ax = 0;               /* 子进程 fork() 返回 0 */
		...
	}
	return 0;
}

ret_from_fork_asm → ret_from_fork() 是新 task 的第一段内核代码。对用户进程，它走 syscall_exit_to_user_mode() 回到用户态；对内核线程，它调用 args->fn(fn_arg)，返回后 do_exit()。

3.4.6 退出：do_exit 与僵尸

退出路径的核心矛盾是：资源要立刻还，但退出码要留着给父进程。do_exit() 把这两件事分开：

/* kernel/exit.c: do_exit() —— 6.8 节选，已简化 */
void __noreturn do_exit(long code)
{
	struct task_struct *tsk = current;
	int group_dead;

	...
	exit_signals(tsk);            /* 设置 PF_EXITING，处理信号 */
	exit_mm();                    /* 释放地址空间（若 mm_users 归零） */
	exit_sem(tsk);
	exit_files(tsk);              /* 关 fd */
	exit_fs(tsk);                 /* 释放 cwd/root */
	exit_task_namespaces(tsk);
	exit_task_work(tsk);
	exit_thread(tsk);
	...
	exit_notify(tsk, group_dead); /* 通知父进程，重新托孤 */
	...
	do_task_dead();               /* 设置 EXIT_DEAD，schedule() 不再返回 */
}

exit_notify() 做两件容易被忽略的事：

1. 重新托孤：如果父进程已死，子进程要么交给 PR_SET_CHILD_SUBREAPER 设置的 subreaper，要么交给 PID 1（find_child_reaper()）。这就是「孤儿进程被 init 收养」的实现。
2. 决定是否变僵尸：如果父进程还在且没有设 SA_NOCLDWAIT，task 进入 EXIT_ZOMBIE，保留 task_struct、退出码、统计信息，等 wait4() 取走。父进程不 wait，僵尸就一直在——每个僵尸占一个 task_struct，不占内存页。

wait4() 的路径：kernel_wait4() → do_wait() → 遍历子进程 → wait_consider_task() → wait_task_zombie() 取退出码，最后 release_task() 做 __exit_signal()、__unhash_process()、put_task_struct()。

退出码的编码是 POSIX 的位约定，用宏读，不要手算：

int status;
pid_t pid = waitpid(child, &status, 0);
if (pid > 0) {
	if (WIFEXITED(status))
		printf("exited, code=%d\n", WEXITSTATUS(status));   /* (status>>8)&0xff */
	else if (WIFSIGNALED(status))
		printf("killed by signal %d, core=%d\n",
		       WTERMSIG(status), WCOREDUMP(status));          /* status & 0x7f */
}

3.4.7 命名空间：同一棵树的不同视图

nsproxy 把一组命名空间指针打包，copy_namespaces() 按 CLONE_NEW* 决定新建还是共享：

/* include/linux/nsproxy.h —— 6.8 节选 */
struct nsproxy {
	refcount_t count;
	struct uts_namespace	*uts_ns;
	struct ipc_namespace	*ipc_ns;
	struct mnt_namespace	*mnt_ns;
	struct pid_namespace	*pid_ns_for_children;
	struct net		*net_ns;
	struct time_namespace	*time_ns;
	struct time_namespace	*time_ns_for_children;
	struct cgroup_namespace	*cgroup_ns;
};

三个常被问到的细节：

• CLONE_NEWPID 影响的是子进程，不是调用者。调用者仍在原命名空间，新建的命名空间由它的子进程「进入」。所以 unshare(CLONE_NEWPID) 之后 getpid() 不变，只有 fork() 出来的孩子看到 PID 1。
• PID 1 在命名空间里是特殊的：没有父进程可托孤，收到未被处理的信号时内核直接忽略（除了 SIGKILL/SIGSTOP 由内核自己处理），这解释了「容器里 kill -9 pid 1 有时没用」。
• setns() 只能进入已有的命名空间，不能进 PID 命名空间改变自己的 PID（只能影响后代）。这也是 nsenter 需要 fork 的原因。

pidfd（5.3+）是这套机制的现代接口：pidfd_open(pid, 0) 得到一个指向 struct pid 的 fd，可以 poll() 等退出、pidfd_send_signal() 发信号，避免了「pid 复用导致杀错进程」的经典竞态。clone3() 的 CLONE_PIDFD 可以在创建时直接拿到 pidfd。

3.4.8 实验：把「共享」与「复制」测出来

第一个实验是一个内核模块：遍历 for_each_process，打印每个进程的 pid、tgid、状态、mm 是否存在、comm。它演示 current、RCU 保护的遍历、以及内核线程 mm == NULL。

// ps_demo.c — 内核态版的 ps（Linux 6.8）
#include <linux/init.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/sched/signal.h>
#include <linux/mm.h>

static int __init ps_demo_init(void)
{
	struct task_struct *p;
	int count = 0;

	rcu_read_lock();                       /* for_each_process 要求 RCU 读锁 */
	for_each_process(p) {
		/* task_struct 在 RCU 宽限期内有效，字段用 READ_ONCE 读 */
		pr_info("pid=%-6d tgid=%-6d state=%-2u mm=%c comm=%s\n",
			task_pid_nr(p), task_tgid_nr(p),
			READ_ONCE(p->__state),
			p->mm ? 'Y' : 'N', p->comm);
		if (++count >= 20)
			break;
	}
	rcu_read_unlock();
	pr_info("ps_demo: printed %d tasks (current=%s pid=%d)\n",
		count, current->comm, current->pid);
	return 0;
}

static void __exit ps_demo_exit(void)
{
	pr_info("ps_demo: unloaded\n");
}

module_init(ps_demo_init);
module_exit(ps_demo_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("walk task list and dump basic fields");

加载后 dmesg 里应看到 kthreadd 的 mm=N、systemd 的 mm=Y，以及内核线程的 tgid == pid。这个模块只读，不改任何状态，是安全的实验。

第二个实验是用户态程序：验证 COW。父进程写一个全局变量，fork() 后子进程改它，父进程看不到变化；再用 mmap(MAP_SHARED) 做对照，子进程的修改父进程能看到。

/* cow_demo.c — 验证 fork 的 COW 与 MAP_SHARED 的差别
 * 编译: cc -std=c17 -D_GNU_SOURCE -Wall -Wextra -O2 -o cow_demo cow_demo.c
 */
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/wait.h>
#include <unistd.h>

static int global_var = 100;

int main(void)
{
	int *shared = mmap(NULL, 4096, PROT_READ | PROT_WRITE,
			   MAP_SHARED | MAP_ANONYMOUS, -1, 0);
	if (shared == MAP_FAILED) { perror("mmap"); return 1; }
	*shared = 200;

	pid_t pid = fork();
	if (pid == -1) { perror("fork"); return 1; }

	if (pid == 0) {
		global_var = 999;        /* 触发 COW：复制一页 */
		*shared = 888;           /* 共享映射：直接写同一页 */
		printf("child : global=%d shared=%d\n", global_var, *shared);
		_exit(0);
	}

	waitpid(pid, NULL, 0);
	printf("parent: global=%d shared=%d\n", global_var, *shared);
	munmap(shared, 4096);
	return 0;
}

预期输出：

child : global=999 shared=888
parent: global=100 shared=888

global 在父进程仍是 100（COW 隔离），shared 变成 888（真共享）。把 MAP_SHARED 改成 MAP_PRIVATE，父进程会看到 200——私有映射的写也走 COW。

3.4.9 观测：/proc 里的进程视图

三个实用组合：

# 1. 进程的所有线程及其状态（L 显示线程，-o 选字段）
ps -eLf -o pid,tid,psr,stat,comm | awk '$2 != $1'

# 2. 谁在等 futex（Java/Go 程序卡住时先看这个）
for t in /proc/$PID/task/*; do
  printf '%s %s\n' "$(basename "$t")" "$(cat "$t"/wchan 2>/dev/null)"
done | sort -k2 | uniq -c -f1 | sort -rn | head

# 3. 线程数与 VmPTE（页表占用）
grep -E 'Threads|VmPTE|VmRSS' /proc/$PID/status

VmPTE 是页表本身占用的内存。一个 fork 频繁、映射很大的服务，VmPTE 可能到几百 MiB——这部分内存不在 VmRSS 里，容易被漏算。VmPMD 是页中间表，同样要看。

3.4.11 task_struct 的字段级解剖：9 KiB 里还有什么

这一节回答：除了 3.4.1 那张分组图，task_struct 里还有哪些字段决定了行为、哪些字段是「每线程」而哪些是「每进程」、thread_info 与内核栈在 6.8 怎么摆。

3.4.1 给了骨架。真正读代码时，下面这些字段出现频率最高，且最容易和相邻概念混淆。

「每进程」那一列的 signal 是理解线程组的关键：utime/stime 虽然记在每个 task 上，但 getrusage(RUSAGE_SELF) 读的是 signal->stats 里汇总后的值；alarm()、setitimer(ITIMER_REAL) 也是线程组共享的，只有 ITIMER_VIRTUAL/PROF 按线程计。

thread_info 与内核栈

6.8 的 thread_info 很小，且嵌在 task_struct 里（CONFIG_THREAD_INFO_IN_TASK=y）：

/* arch/x86/include/asm/thread_info.h —— 6.8 节选 */
struct thread_info {
	unsigned long		flags;		/* TIF_* 低层标志 */
	unsigned long		syscall_work;	/* 系统调用返回时要处理的工作 */
	u32			status;		/* 线程同步状态 */
	u32			cpu;		/* 当前 CPU（CONFIG_SMP） */
};

它不再位于内核栈顶端，所以 current 不能靠「栈指针与 THREAD_SIZE 对齐」算出来。x86-64 的 current 读 per-CPU 的 current_task：

/* arch/x86/include/asm/current.h —— 6.8 节选 */
static __always_inline struct task_struct *get_current(void)
{
	return this_cpu_read_stable(current_task);
}
#define current get_current()

this_cpu_read_stable() 告诉编译器「这个 per-CPU 变量在上下文切换后由内核更新」，允许它把值缓存到寄存器——比每次都读 %gs 快，但要求切换代码正确更新 current_task（__switch_to() 里做）。

内核栈的布局：

高地址
  ┌──────────────────────────────┐
  │ pt_regs（用户态寄存器）       │  ← task_pt_regs(p)
  ├──────────────────────────────┤
  │ 内核栈（向下增长）            │
  │ ...                          │
  │ 当前 RSP                     │
  └──────────────────────────────┘
低地址
  thread.sp 指向切换时保存的栈帧（inactive_task_frame）

THREAD_SIZE 在 x86-64 是 16 KiB（4 * PAGE_SIZE，order-2）。CONFIG_VMAP_STACK=y 时栈从 vmalloc 区分配，前后各加一页 guard page；栈溢出触发 #PF，而不是静默踩坏相邻内存。CONFIG_DEBUG_STACK_USAGE 会在 check_stack_usage() 里统计「历史最低剩余」，启动日志里的 stack guard gap 与 /proc/PID/stack 都依赖它。

task_struct 本身从 task_struct_cachep 分配，fork_init() 按物理内存大小算 max_threads，并创建这个 slab cache。9 KiB 的对象跨越 3 个 4 KiB 页，SLUB 会为它单独建 order-2 的 slab。

3.4.12 copy_process 的失败路径：每个 goto 都是一次回滚

这一节回答：copy_process() 中途失败会留下什么、错误标签为什么按相反顺序排列、clone3() 比 clone() 多了什么。

3.4.3 给了 copy_process() 的成功顺序。真正体现功力的是失败路径：十几步里任何一步失败，都要把前面已建立的资源按相反顺序拆掉。

错误标签链

/* kernel/fork.c: copy_process() —— 6.8 节选，只保留标签 */
bad_fork_free_pid:
	if (pid != &init_struct_pid)
		free_pid(pid);
bad_fork_cancel_cgroup:
	cgroup_cancel_fork(p);
bad_fork_cleanup_thread:
	exit_thread(p);
bad_fork_cleanup_io:
	if (p->io_context)
		exit_io_context(p);
bad_fork_cleanup_namespaces:
	exit_task_namespaces(p);
bad_fork_cleanup_mm:
	if (p->mm) {
		mmap_write_lock(p->mm);
		mmput(p->mm);
		mmap_write_unlock(p->mm);
	}
bad_fork_cleanup_signal:
	if (!(clone_flags & CLONE_THREAD))
		free_signal_struct(p->signal);
bad_fork_cleanup_sighand:
	__cleanup_sighand(p->sighand);
bad_fork_cleanup_fs:
	exit_fs(p);
bad_fork_cleanup_files:
	exit_files(p);
bad_fork_cleanup_semundo:
	exit_sem(p);
bad_fork_cleanup_creds:
	if (retval == -EAGAIN)
		p->cred = p->real_cred = get_cred(p->cred);
bad_fork_cleanup_sched:
	put_task_struct(p);
bad_fork_free_task:
	free_task(p);

读这段代码的方法：从失败点往上倒着看。比如 alloc_pid() 失败跳到 bad_fork_cancel_cgroup，它只取消 cgroup 与 pid，不会碰 mm/files——因为那些还没建立。每一步的标签只清理「这一步之前已经成功的事」，多清一个就是 double free，少清一个就是泄漏。

bad_fork_cleanup_creds 的 -EAGAIN 分支值得注意：copy_creds() 在 CLONE_THREAD 且 cred 已被别的线程替换时会返回 -EAGAIN，此时新 task 还没持有自己的 cred 引用，必须补一个 get_cred() 再走清理，否则 put_cred() 会把共享的 cred 释放掉。

失败原因与 errno

三条实践结论：

1. EAGAIN 不等于「内存不足」：RLIMIT_NPROC、max_threads、PID 耗尽、sched_fork 都可能返回它。fork() 失败时先看 ulimit -u 与 /proc/sys/kernel/pid_max。
2. PID 耗尽是「慢故障」：pid_max 默认 32768，回绕后新进程复用旧号；如果有进程长期不回收，alloc_pid 会一直失败。/proc/sys/kernel/ns_last_pid 能看到当前分配位置。
3. 错误分支里的 mmput() 要拿 mmap_write_lock：释放地址空间会改页表，必须与并发的缺页/mmap 串行化；这也是 copy_process 里少数几处显式拿 mmap_write_lock 的地方。

clone3() 与 clone() 的差别

clone() 的参数是「标志 + 栈 + 5 个可选参数」，无法扩展；clone3() 用结构体：

/* include/uapi/linux/sched.h —— 6.8 节选 */
struct clone_args {
	__aligned_u64 flags;
	__aligned_u64 pidfd;
	__aligned_u64 child_tid;
	__aligned_u64 parent_tid;
	__aligned_u64 exit_signal;
	__aligned_u64 stack;
	__aligned_u64 stack_size;
	__aligned_u64 tls;
	__aligned_u64 set_tid;
	__aligned_u64 set_tid_size;
	__aligned_u64 cgroup;
};

clone3() 多出的能力：

set_tid 是 CRIU 热迁移的关键：恢复进程时要保持原来的 PID；CLONE_INTO_CGROUP 则避免了「创建后再迁移」的窗口期。两者都需要额外权限，普通进程用不到。

3.4.13 struct pid 与 PID 命名空间：一个进程为什么有多个号

这一节回答：struct pid 为什么不存一个整数、task_pid_nr() 与 pid_vnr() 有什么区别、pidfd 怎么避免「杀错进程」。

3.4.7 提到 struct pid 存「每层一个编号」。展开看它的查找与生命周期。

数据结构

/* include/linux/pid.h —— 6.8 节选 */
struct pid {
	refcount_t count;
	unsigned int level;              /* 命名空间层数，初始命名空间为 0 */
	spinlock_t lock;
	struct hlist_head tasks[PIDTYPE_MAX];
	struct rcu_head rcu;
	struct upid numbers[];
};

struct upid {
	int nr;
	struct pid_namespace *ns;
};

level 是「这个 pid 属于几层命名空间」：初始命名空间 level=0，容器里创建的进程 level=1，嵌套容器 level=2。numbers[] 是柔性数组，长度 level+1，每层一个 upid。

tasks[PIDTYPE_MAX] 的四个槽位对应四种用途：

同一个 struct pid 可以同时挂在四个槽位里（比如一个进程既是线程组长又是进程组长）。hlist_head 里挂的是 task_struct 的 pid_links[] 节点。

编号的三种读法

task_pid_nr() 对内核线程返回 0（它们不在用户命名空间里）。容器里 ps 看到 PID 1，宿主上 ps 看到的是它的全局号——两个号指向同一个 struct pid，只是 numbers[] 的不同项。

查找：RCU 与哈希

find_task_by_vpid(vnr) 在当前命名空间里查找：

find_task_by_vpid(vnr)
  → find_pid_ns(vnr, task_active_pid_ns(current))
      → idr_find(&ns->idr, vnr)            /* 返回 struct pid */
  → pid_task(pid, PIDTYPE_PID)             /* 取 tasks[PIDTYPE_PID] 第一个 */

idr_find() 是 RCU 读，不需要锁；pid_task() 返回的 task_struct 可能下一秒退出，所以调用者要么持有 rcu_read_lock()，要么用 get_pid_task() 增加引用。kill(2) 的路径就是这样：

/* kernel/signal.c: kill_pid_info() —— 6.8 节选，已简化 */
rcu_read_lock();
p = pid_task(pid, PIDTYPE_PID);
if (p)
	error = group_send_sig_info(sig, info, p, PIDTYPE_TGID);
rcu_read_unlock();

rcu_read_lock() 保证 task_struct 在发送信号期间不被释放；信号入队后，即使 task 立刻退出，signal_struct 的引用也会保证队列有效。

pidfd：把「号」变成「引用」

PID 会回绕。经典的竞态是：

进程 A: pid = fork(); 记录 pid=1234
进程 B: 1234 退出，系统分配新进程也用 1234
进程 A: kill(1234, SIGKILL)   ← 杀错了

pidfd 用 fd 持有 struct pid 的引用，彻底消除这个窗口：

int pidfd = pidfd_open(1234, 0);       /* 5.3+ */
if (pidfd >= 0) {
	/* 之后 1234 即使被复用，pidfd 仍指向原进程 */
	pidfd_send_signal(pidfd, SIGKILL, NULL, 0);
	poll(&(struct pollfd){.fd = pidfd, .events = POLLIN}, 1, -1); /* 等退出 */
}

pidfd 让「等待进程退出」变成 poll()，可以和 socket、timer 一起进 epoll——这是 systemd、容器运行时替代「waitpid + 信号」的关键。

3.4.14 凭证、seccomp 与 LSM：谁能改变「我是谁」

这一节回答：cred 为什么是 RCU 替换而不是就地修改、线程之间共享 cred 意味着什么、seccomp 与 LSM 在哪个钩子上拦住系统调用。

struct cred：不可变的身份快照

/* include/linux/cred.h —— 6.8 节选 */
struct cred {
	atomic_long_t	usage;
	kuid_t		uid;		/* 真实 UID */
	kgid_t		gid;
	kuid_t		suid;		/* 保存的 UID（setuid 用） */
	kgid_t		sgid;
	kuid_t		euid;		/* 有效 UID：权限检查看它 */
	kgid_t		egid;
	kuid_t		fsuid;		/* 文件访问 UID（NFS 用） */
	kgid_t		fsgid;
	unsigned	securebits;
	kernel_cap_t	cap_inheritable;
	kernel_cap_t	cap_permitted;
	kernel_cap_t	cap_effective;
	kernel_cap_t	cap_bset;	/* bounding set */
	kernel_cap_t	cap_ambient;
	...
	struct user_struct *user;
	struct user_namespace *user_ns;
	struct group_info *group_info;
	struct rcu_head	rcu;
};

cred 一旦发布就不再修改。要改身份，走「复制—修改—替换」：

prepare_creds()       复制当前 cred，返回可写副本
  → 修改 uid/cap/...
commit_creds(new)     RCU 替换 current->cred，旧 cred 延迟释放
  → 失败：abort_creds(new)

commit_creds() 里用 rcu_assign_pointer(current->real_cred, new) 与 rcu_assign_pointer(current->cred, new)，旧 cred 通过 put_cred() → call_rcu() 释放。这样所有「正在用旧 cred 做权限检查」的读者不会看到半更新的字段。

override_creds()/revert_creds() 是临时借用：nfsd、overlayfs 在内核里以「调用者的身份」访问文件时用。它们也返回旧 cred，必须配对。

线程组共享 cred

copy_creds() 的分支：

/* kernel/cred.c: copy_creds() —— 6.8 节选，已简化 */
int copy_creds(struct task_struct *p, unsigned long clone_flags)
{
	struct cred *new;
	int ret;

	if (clone_flags & CLONE_THREAD) {
		/* 线程共享线程组的 cred */
		p->real_cred = get_cred(p->cred);
		p->cred = get_cred(p->cred);
		return 0;
	}
	new = prepare_creds();
	if (!new)
		return -ENOMEM;
	...
	p->cred = p->real_cred = get_cred(new);
	return 0;
}

所以一个线程调用 setuid()，整个线程组都变——POSIX 要求如此。反过来，setresuid() 在多线程程序里必须用 glibc 的 nptl 协调（向所有线程发信号让它们同步），否则会出现「一个线程已降权、另一个还没降」的窗口。

cap_effective 是实际生效的权能集合；cap_permitted 是允许的上限；cap_bset（bounding set）是「就算 setuid root 也拿不到」的硬上限。容器运行时通过 capset() 与 prctl(PR_CAPBSET_DROP) 收缩这些集合。

seccomp：在系统调用入口做过滤

seccomp 的三种模式：

过滤器结构：

/* include/linux/seccomp.h —— 6.8 节选 */
struct seccomp_filter {
	refcount_t refs;
	refcount_t users;
	bool log;
	bool wait_killable_recv;
	struct action_cache cache;
	struct seccomp_filter *prev;	/* 过滤器链，后装的先执行 */
	struct bpf_prog *prog;
	struct notification *notif;
	struct mutex notify_lock;
};

seccomp(SECCOMP_SET_MODE_FILTER, flags, &prog) 把 BPF 程序挂到当前线程（SECCOMP_FILTER_FLAG_TSYNC 可同步到整个线程组）。之后每次系统调用，syscall_trace_enter() 里 seccomp_run_filters() 依次执行过滤器链，返回一个 SECCOMP_RET_* 动作：

USER_NOTIF 是容器运行时的关键：runc 用它在执行危险系统调用前做检查（如 mount），把决定权交给宿主上的 supervisor。SECCOMP_RET_ERRNO 则让「拒绝」看起来像普通错误，避免应用崩溃。

启用 filter 需要 no_new_privs=1（或 CAP_SYS_ADMIN）：prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)。这是为了防止「setuid 程序被过滤器绕过」——一旦 no_new_privs，execve 不再提权，过滤器无法被甩掉。

LSM：另一层钩子

seccomp 过滤的是「系统调用号与参数」，LSM 过滤的是「语义」：

/proc/PID/status 里能看到结果：

CapEff:	00000000a80425fb
NoNewPrivs:	1
Seccomp:	2
Seccomp_filters:	3

Seccomp: 2 表示 filter 模式，Seccomp_filters: 3 是过滤器链长度。CapEff: 0 表示没有有效权能；容器里 CapEff 通常是 a80425fb（去掉 CAP_SYS_ADMIN 等）。

3.4.15 进程的时间：utime、stime 与 POSIX 定时器

这一节回答：ps 的 TIME 列从哪来、/proc/PID/stat 的 utime/stime 单位是什么、nanosleep 与 setitimer 在内核里用哪种定时器。

进程的时间记账分三层：调度器账本（sum_exec_runtime）、用户可见账本（utime/stime）、定时器（hrtimer/posix-cpu-timer）。

字段与更新点

更新点在上下文切换与 tick：

__schedule()
  → finish_task_switch()
      → account_user_time(prev, delta) / account_system_time(...)
      → acct_update_integrals(prev)

scheduler_tick()
  → task_tick_*()
      → update_curr()  累计 sum_exec_runtime

account_user_time() 把 delta 加到 p->utime 与 signal->utime；account_system_time() 加到 stime。acct_update_integrals() 把 sum_exec_runtime 的增量换算成 utime/stime，并更新 prev_cputime。这套记账在 CONFIG_VIRT_CPU_ACCOUNTING_GEN 下更精确（读 CPU 的 accounting 寄存器），否则按 tick 采样，精度是 1/HZ。

用户态读到的三个口径

USER_HZ 固定为 100（include/asm-generic/param.h），不随 CONFIG_HZ 变；所以 /proc/PID/stat 的时间分辨率是 10 ms，而 clock_gettime(CLOCK_PROCESS_CPUTIME_ID) 是 ns（实际精度取决于记账粒度）。

ps 的 TIME 列是把 utime+stime 按 USER_HZ 换算后格式化的；top 的 %CPU 是「一秒内 utime+stime 的增量」。两者都不包含已回收子进程的时间（那在 cutime/cstime 里）。

定时器：三种时钟、三种信号

ITIMER_REAL 用 hrtimer，因为它是墙钟；ITIMER_VIRTUAL/PROF 用 posix-cpu-timer，因为它们依赖 CPU 时间记账，只能在 tick 或返回用户态时检查。

nanosleep 的路径：

nanosleep(req, rem)
  → hrtimer_nanosleep()
      → do_nanosleep()
          → schedule_hrtimeout_range(&expires, slack, HRTIMER_MODE_ABS)
              → schedule() 直到 hrtimer 到期或被信号唤醒
      → 被信号打断：返回 -EINTR，剩余时间写回 rem

nanosleep 的 rem 是「被信号打断后还剩多久」，这是它与 sleep() 的关键差别（sleep() 不返回剩余时间）。clock_nanosleep 支持 TIMER_ABSTIME，避免「相对时间 + 调度延迟」的累积误差。

sched_clock() 与 ktime_get()

内核里有两套时间：

• ktime_get() / ktime_get_mono_fast_ns()：基于 clocksource（TSC、HPET、ACPI PM）的墙钟/单调钟，可能被 NTP 调整；
• sched_clock()：调度器专用，要求「快、单调、跨 CPU 可比」，通常直接用 TSC，不参与 NTP。

task->start_time 用 sched_clock() 记录（/proc/PID/stat 的 starttime 是它换算成 tick），task->start_boottime 用 boottime。两者在系统休眠/时间调整后可能分叉，比较「进程活了多久」时要用 monotonic 口径（clock_gettime(CLOCK_MONOTONIC) - start_time）。

3.4.16 任务释放与 RCU：task_struct 什么时候真的消失

这一节回答：release_task() 之后 task_struct 为什么还在、put_task_struct_rcu_user() 与 put_task_struct() 差在哪、内核栈什么时候释放。

3.4.6 讲到 do_exit() 把 task 变成僵尸，wait4() 调 release_task()。释放分两段：

release_task(task)
  → __exit_signal(task)          从 signal_struct 摘除，统计退出
  → __unhash_process(task)       从 pid 哈希、线程组链表摘除
  → put_task_struct_rcu_user(task)   挂 RCU 回调
      → call_rcu(&task->rcu, delayed_put_task_struct)
          → 宽限期后：put_task_struct(task)
              → refcount 归零：__put_task_struct()
                  → exit_creds(task)
                  → put_task_stack(task)     释放内核栈（vmap stack）
                  → free_task(task)
                      → kmem_cache_free(task_struct_cachep, task)

为什么要 RCU？因为 find_task_by_vpid() 之类的查找是 RCU 读：读者拿到 task_struct 指针后不加锁就访问字段。如果 release_task() 立刻 kfree()，读者就踩空。call_rcu() 等到所有「已经开始的 RCU 读临界区」结束后再释放。

两个 put_task_struct 变体容易混：

delayed_put_task_struct() 是回调函数，它在宽限期后调用 put_task_struct()。如果还有别的引用（如 ptrace、/proc 打开着），refcount 不会归零，free_task() 推迟到最后一个引用释放。

free_task() 的顺序也有讲究：

/* kernel/fork.c: free_task() —— 6.8 节选，已简化 */
void free_task(struct task_struct *tsk)
{
	...
	put_task_stack(tsk);              /* vmap stack：释放 guard page 与映射 */
	...
	arch_release_task_struct(tsk);    /* 架构相关（FPU、xstate） */
	free_task_struct(tsk);            /* kmem_cache_free(task_struct_cachep) */
}

内核栈不能早于 task_struct 释放：free_task() 自己还在栈上跑。put_task_stack() 在 CONFIG_VMAP_STACK 下走 vfree()，并释放 guard page；在普通配置下走 free_pages()。

僵尸与「已死但未释放」

三种状态要分清：

/proc/PID/status 的 State: Z 是僵尸；/proc/PID/stat 的 exit_code 是退出码。僵尸本身不占内存页，只占一个 task_struct 与 pid 号；大量僵尸会耗尽 pid_max，导致新进程 fork 失败。

3.4.17 观测：fork/exec/exit 的 tracepoint 与 /proc 视图

这一节回答：怎么量出「谁在疯狂 fork」「copy_process 慢在哪」「一个进程的 cred、cgroup、栈、调度信息分别在哪看」。

sched tracepoint

include/trace/events/sched.h 定义了进程生命周期的四个事件：

# 每秒 fork 最多的进程
sudo bpftrace -e '
tracepoint:sched:sched_process_fork { @[str(args->parent_comm)] = count(); }
interval:s:5 { print(@); clear(@); }'

# copy_process 的耗时分布（微秒），含失败
sudo bpftrace -e '
kprobe:copy_process { @s[tid] = nsecs; }
kretprobe:copy_process /@s[tid]/ {
	@us = hist((nsecs - @s[tid]) / 1000);
	delete(@s[tid]);
}'

# 谁在执行什么程序
sudo bpftrace -e '
tracepoint:sched:sched_process_exec {
	printf("%-16s pid=%-6d file=%s\n", comm, pid, str(args->filename));
}'

perf 侧可以用 perf trace -e clone,clone3,execve,exit_group 看系统调用级视图，perf sched latency 看调度延迟。perf sched record 记录后 perf sched script 能还原每次 sched_switch 的调用栈。

/proc/PID 的关键文件

/proc/PID/sched 里的 nr_voluntary_switches 与 nr_involuntary_switches 是判断「进程是被抢还是自己让」的关键：

• 自愿切换高：进程在等 I/O、锁、sleep；
• 非自愿切换高：CPU 竞争激烈或实时任务抢占；
• se.sum_exec_runtime 是调度器账本，与 utime+stime 不一定相等（后者按 tick 采样）。

一个进程的「身份快照」

pid=$$
grep -E '^(Name|State|Tgid|Pid|PPid|Threads|CapEff|Seccomp|NoNewPrivs)' /proc/$pid/status
readlink /proc/$pid/ns/pid /proc/$pid/ns/mnt
cat /proc/$pid/sched | head -8

这四组输出分别对应：task 基本状态、权能/过滤器、命名空间、调度统计。排查容器问题时，先比较两个进程的 /proc/PID/ns/* inode 是否相同——相同才是同一个命名空间。

3.4.18 实验：clone 的共享与 fork 的复制

这一节给两个可运行实验：一个用户态程序对比 clone(CLONE_VM|...) 与 fork() 的可见性；一个内核模块打印 task_struct 的关键字段。均在 QEMU（Linux 6.8，x86-64）验证流程，未在真机实测。

实验一：共享一个全局变量

/* clone_share.c — clone 共享 vs fork 复制
 * 编译: cc -std=c17 -D_GNU_SOURCE -Wall -Wextra -Werror -O2 -o clone_share clone_share.c
 */
#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/wait.h>
#include <unistd.h>

static int global_var = 1;

static int thread_fn(void *arg)
{
	(void)arg;
	global_var = 42;          /* CLONE_VM：改的是同一块内存 */
	return 0;
}

int main(void)
{
	const size_t stack_size = 1 << 20;
	char *stack;
	pid_t pid;

	stack = mmap(NULL, stack_size, PROT_READ | PROT_WRITE,
		     MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0);
	if (stack == MAP_FAILED) {
		perror("mmap");
		return 1;
	}

	pid = clone(thread_fn, stack + stack_size,
		    CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD,
		    NULL);
	if (pid < 0) {
		perror("clone");
		return 1;
	}
	sleep(1);                 /* 等线程跑完；生产代码应使用 futex/join */
	printf("after clone : global_var=%d (expect 42)\n", global_var);

	global_var = 1;
	pid = fork();
	if (pid < 0) {
		perror("fork");
		return 1;
	}
	if (pid == 0) {
		global_var = 42;  /* fork：改的是自己的副本 */
		_exit(0);
	}
	waitpid(pid, NULL, 0);
	printf("after fork  : global_var=%d (expect 1)\n", global_var);
	return 0;
}

预期输出：

after clone : global_var=42 (expect 42)
after fork  : global_var=1 (expect 1)

两个注意点：

• 这个 clone() 没有设置 TLS，子函数里不能用 errno、printf、malloc 等依赖线程局部存储的函数；真实线程库会先建 TLS。
• CLONE_THREAD 要求同时有 CLONE_SIGHAND 与 CLONE_VM，否则 clone() 返回 EINVAL。这是内核强制的组合约束。

把 CLONE_VM 去掉，clone() 立即失败；把 CLONE_THREAD 去掉但保留 CLONE_VM，得到的是一个「共享地址空间但不属于同一线程组」的怪东西——getpid() 不同、退出会发 SIGCHLD，这正是 vfork 的形态。

实验二：内核态看 task_struct

// taskinfo.c — 打印 task_struct 关键字段（Linux 6.8）
#include <linux/cred.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/sched/signal.h>
#include <linux/sched/task_stack.h>
#include <asm/thread_info.h>

static int max_tasks = 8;
module_param(max_tasks, int, 0444);
MODULE_PARM_DESC(max_tasks, "how many tasks to print");

static int __init taskinfo_init(void)
{
	struct task_struct *p;
	int n = 0;

	rcu_read_lock();
	for_each_process(p) {
		if (n++ >= max_tasks)
			break;
		pr_info("task pid=%d tgid=%d comm=%s state=%u flags=%#x mm=%px uid=%u\n",
			task_pid_nr(p), task_tgid_nr(p), p->comm,
			READ_ONCE(p->__state), p->flags, p->mm,
			from_kuid(&init_user_ns, p->cred->uid));
	}
	rcu_read_unlock();

	pr_info("current pid=%d tgid=%d comm=%s\n",
		current->pid, current->tgid, current->comm);
	pr_info("stack=%px sp=%#lx THREAD_SIZE=%lu in_interrupt=%d preempt=%#x\n",
		current->stack, current->thread.sp, (unsigned long)THREAD_SIZE,
		in_interrupt(), preempt_count());
	return 0;
}

static void __exit taskinfo_exit(void) { }

module_init(taskinfo_init);
module_exit(taskinfo_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("dump task_struct fields");

加载后 dmesg 输出（节选）：

task pid=1 tgid=1 comm=systemd state=1 flags=0x400040 mm=00000000a1b2c3d4 uid=0
task pid=2 tgid=2 comm=kthreadd state=1 flags=0x402040 mm=0000000000000000 uid=0
...
current pid=312 tgid=312 comm=insmod
stack=ffffc90000a1c000 sp=0xffffc90000a1fd20 THREAD_SIZE=16384 in_interrupt=0 preempt=0x0

三个观察：

• kthreadd 的 mm=0，证明内核线程没有用户地址空间；
• THREAD_SIZE=16384 是 16 KiB；stack 在 ffffc9... 区间说明 CONFIG_VMAP_STACK=y；
• insmod 的 preempt=0x0、in_interrupt=0，说明模块 init 在进程上下文。

把 for_each_process 换成 for_each_process_thread 能看到每个线程；task_pid_nr() 与 task_tgid_nr() 在单线程进程里相等，在线程里不同。

3.4.19 陷阱清单：进程与线程篇

3.4.20 本章出口检查

母本对应

下一站：3.5 调度器 接手就绪队列：task_struct 里的 sched_entity 怎么被排序、vruntime 与 EEVDF 的 deadline 有什么区别、实时进程凭什么抢占普通进程。