搞内核的兄弟应该都见过这个变化：5.x内核里那个经典入口do_fork悄悄退场，取而代之的是kernel_clone。我最早是在翻kernel/fork.c时发现的，心里还愣了一下，以为代码回退到某个开发分支了。后来顺着提交记录一看才明白，这不是简单的改名，而是把fork/clone这一族代码做了一次系统性重构。用户态看到的fork()、vfork()、clone()，内核态里天天要用的kernel_thread()，最后全部收束到同一个函数上——kernel_clone。凡是跟进程、线程创建相关的疑难杂症，循着调用栈追到深处，最终都会站在这个函数门口。
这篇文章准备把kernel_clone彻底拆开：它为什么会出现、调用链怎么走、参数结构体每个字段是什么意思、copy_process内部几百行代码到底按什么顺序做了什么、以及我在实际排查中踩过的坑和用过的工具。适合刚接触内核开发、想弄懂进程创建全流程的读者，也适合遇到fork类问题却不知道从哪下手的开发者。
1. 从do_fork到kernel_clone：一次不得不做的重构
老内核里，进程创建的核心入口是do_fork，它的原型在相当长一段时间里保持着这种风格：
long do_fork(unsigned long clone_flags, unsigned long stack_start, unsigned long stack_size, int __user *parent_tidptr, int __user *child_tidptr, unsigned long tls);看起来也不算太离谱，但你只要在这个函数上增加任何一个语义参数，就得把整条调用链上所有上层函数全部跟着改。内核里真正会调用do_fork的地方远不止系统调用入口，kernel_thread()、kthread_create()、以及后来逐渐出现的clone3准备逻辑，都要跟这一长串参数对齐。参数越来越多，逐个排列下去，可读性下降，更麻烦的是扩展成本高得离谱。
5.x的重构方向很明确：把参数封装进一个结构体，函数只接收结构体指针。于是就有了：
static pid_t kernel_clone(struct kernel_clone_args *args)从do_fork到kernel_clone的改名，本质是一套接口的重新设计，并不是新增一个并列函数。老代码里很多do_fork的调用点全部迁移到kernel_clone，逻辑一脉相承，但参数从散装改成了打包。这个过程中，维护者顺手把很多原本散落各处的参数合法性检查统一收口到copy_process里，让进程创建的核心路径变得更清晰。
举一个具体的例子。clone3系统调用落地时，新增了set_tid数组、cgroup参数这类东西。如果还沿用do_fork那种散装参数风格，光是兼容新旧接口就要写一堆丑陋的桥接代码。但有了kernel_clone_args结构体，clone3的解析层只需要把用户传入的数据翻译成结构体字段，后面所有函数零改动就能继续工作。设计者可以像搭积木一样给结构体加字段，同时通过CLONE_*标志位控制哪些字段有效，这让ABI的演进变得平滑很多。
说句实在话，初看这个改名可能觉得只是风格洁癖，但深入进去会发现，参数结构体化是内核接口演进里非常重要的一步棋。往小了说，把一个函数的签名稳定住；往大了说，它决定了后续能不能安全地扩出clone3这种新接口。kernel_clone就是这一系列设计的枢纽。
2. 三大入口如何汇合到kernel_clone
理解kernel_clone，先要搞清楚谁会调它。进程创建这件事，用户态看到的接口五花八门，但内核态的入口无非三大类：fork/vfork/clone三个系统调用，以及只供内核内部使用的kernel_thread。
2.1 用户态系统调用入口
以x86_64为例，应用层调用fork()时，glibc封装实际发起的是clone系统调用，带SIGCHLD标志。内核收到__NR_clone或者老的__NR_fork、__NR_vfork之后，在kernel/fork.c里分别走对应的包装函数，最终都构建一个struct kernel_clone_args，然后调kernel_clone：
SYSCALL_DEFINE0(fork) { struct kernel_clone_args args = { .exit_signal = SIGCHLD, }; return kernel_clone(&args); }vfork的入口也类似，区别在于它会额外设置CLONE_VM和CLONE_VFORK并依然使用SIGCHLD。而clone系统调用的包装函数则要麻烦一些，因为参数太多，老式clone有一部分参数要从用户态栈里取，这涉及用户栈访问的拷贝逻辑。
这里有个很多人忽视的细节：用户态fork()和vfork()在x86_64上并不一定真的走__NR_fork和__NR_vfork，glibc可能直接用clone系统调用实现。内核里保留SYSCALL_DEFINE0(fork)更多是给那些确实使用老系统调用号的场景做兼容。所以你在/proc/kallsyms里看到__do_sys_clone调用频率远高于__do_sys_fork，就不要觉得奇怪。
2.2 clone3的现代入口
clone3系统调用是后来加入的，它的设计理念和clone完全不同。clone的老问题在于参数太依赖寄存器与用户栈布局，不同架构上的参数传递规则不同，还容易出TOCTOU类的安全问题。clone3干脆让用户态传入一个结构体指针，内核先把整个结构体拷贝到内核空间，再逐字段校验，最后翻译成kernel_clone_args：
SYSCALL_DEFINE2(clone3, struct clone_args __user *, uargs, size_t, size)注意这里的size参数。clone_args是允许扩展的，新内核会定义更多字段，用户态传入的size表示自己使用的结构体长度。如果用户态结构体比内核当前支持的短，内核对未提供的字段自动取零；如果比内核支持的长，内核会校验未知标志位并拒绝。这样做既保证了向前兼容，也避免了老式clone那种从用户栈现场抠参数的脆弱方式。
2.3 内核态kernel_thread入口
内核自己创建内核线程，入口是kernel_thread()，它在很多驱动里都能见到。它的实现并不复杂，本质上就是组装一个kernel_clone_args然后调kernel_clone：
pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags) { struct kernel_clone_args args = { .flags = ((lower_32_bits(flags) | CLONE_UNTRACED) & ~CSIGNAL), .exit_signal = (lower_32_bits(flags) & CSIGNAL), .fn = fn, .fn_arg = arg, }; return kernel_clone(&args); }注意它在flags里强制加了CLONE_UNTRACED。这意味着内核线程创建时，ptrace机制不会介入，不会向调试器报告任何事件。这是内核线程与用户进程最本质的一个区别。
另外一个容易错过的小点：kernel_thread里.fn字段不为空。这个字段到了copy_process里会被特殊判断，直接决定新任务走内核线程的初始化路径，还是一个完整的用户态进程复制路径。可以说，fn字段是kernel_clone_args里最“轴心”的一个开关，后面讲copy_process的时候你会看到它带来的连锁差异。
3. kernel_clone_args逐字段拆解
想深入理解kernel_clone，绕不开struct kernel_clone_args。我在5.15内核里常看到的定义大致是这样：
struct kernel_clone_args { u64 flags; int __user *pidfd; int __user *child_tidptr; int __user *parent_tidptr; const char *name; int exit_signal; u64 stack; u64 stack_size; u64 tls; pid_t *set_tid; size_t set_tid_size; int (*fn)(void *); void *fn_arg; };每个字段都有明确的分工，下面逐个过。
关于flags，它继承自老do_fork的clone_flags，是控制进程创建行为的总开关。所有CLONE_*标志位都汇聚在这里。后面的字段是否有效，很大程度由flags里的对应位决定，比如设置CLONE_CHILD_SETTID时，child_tidptr才有意义；设置CLONE_PARENT_SETTID时，parent_tidptr才有意义。
pidfd是CLONE_PIDFD标志引入的产物。用户态通过clone3创建进程时，内核可以顺便返回一个代表新进程的pidfd文件描述符，写进用户态地址。这个机制让进程存活状态变得可以用poll或epoll监听，远比传统的waitpid异步化容易。老式clone系统调用没有专门字段放pidfd，只能复用parent_tidptr的位置返回fd，所以kernel_clone里一上来就要做检查：
if (args->pidfd && (clone_flags & CLONE_PARENT_SETTID)) return -EINVAL;因为CLONE_PIDFD和CLONE_PARENT_SETTID都会向用户态写入值，但地址是同一个，同时使用就会产生干扰，内核直接拒绝这种组合。
child_tidptr和parent_tidptr是给线程库用的。以NPTL为例，线程创建时设置这两个地址，内核在新线程首次被调度或退出时往这些地址写特定值。parent_tidptr在CLONE_PARENT_SETTID时负责把新线程的pid写回父进程指定地址；child_tidptr在CLONE_CHILD_CLEARTID和CLONE_CHILD_SETTID时分别负责退出时清空、创建时写入字段，这是futex机制加速线程同步的基础。
name字段属于后来的扩展。它让内核线程创建时可以直接指定线程名字，省去了创建后再调kthread_rename之类操作的麻烦。kthread_create路径里会用这个字段把task的可读名字在copy_process阶段就定下来。
exit_signal决定子进程在退出时向父进程发送哪个信号。常规fork时它是SIGCHLD，所以父进程能用wait()捡到子进程状态；线程创建时它通常为0，表示不产生信号，子线程退出不干扰父进程的wait逻辑。kernel_clone里对exit_signal还有一个隐藏用途，下面讲到ptrace事件选择时会看到。
stack和stack_size用于指定用户态调度栈。线程创建时，调用者往往已经准备好一块新栈，这些字段告诉内核新进程的用户栈位置和大小。普通fork时栈是父进程当前栈的延续，不需要这两个字段。
tls字段用于CLONE_SETTLS，指定新进程的线程局部存储描述符。这个字段在不同架构上的语义略有差异，但整体都是把用户态线程库需要的TLS信息传递给新任务。
set_tid和set_tid_size是clone3新增的能力。它允许用户指定新进程在某些层级的PID命名空间里具体使用什么PID编号。举个例子，如果进程处于多级PID命名空间，你可以在最内层指定一个固定PID，让某些对启动顺序敏感的应用可以复现。这个字段在老式clone里完全不存在，是结构体化重构之后才能安全塞进来的典型新特性。
fn和fn_arg专门给内核线程用。fn就是新内核线程要执行的函数指针，fn_arg是这个函数收到的参数。只要fn不为空，copy_process就会放弃复制用户态地址空间，转而去构建一个没有mm的内核线程。
从这些字段能看出，kernel_clone_args其实合并了很多原本分散在不同系统调用里的参数，让进程创建的全部信息以统一结构流入同一个函数。也正因如此，内核态对参数做集中校验变得容易，用户态各种标志组合的合法性检查也清晰了。
4. copy_process内部流水线逐段拆解
kernel_clone本体代码量并不大，真正干活的是copy_process。如果你把copy_process比作一条流水线，kernel_clone就是流水线入口的调度员：负责选择ptrace事件、处理vfork等待、把子进程加入运行队列，以及向用户态写回各种返回值。下面按顺序拆这条流水线。
4.1 入口检查与内核线程分支
copy_process一进来，先做一堆标志位合法性校验。大量CLONE_*组合是有硬性约束的，比如CLONE_THREAD要求同时设置CLONE_SIGHAND和CLONE_VM，因为线程组必须共享信号处理函数和内存空间。内核里这些检查写得很直白，标志位组合不合法直接返回错误。
紧接着是一个关键分支：
if (args->fn) { p->mm = NULL; p->flags |= PF_KTHREAD; } else { retval = copy_mm(clone_flags, p); }args->fn不为空，说明这是kernel_thread路径。新任务直接不设置mm，并打上PF_KTHREAD标记。内核线程是没有用户地址空间的，它访问用户内存时必须借用其他进程的active_mm，这是调度器层面处理的事。这里不调用copy_mm，等于把几百行内存复制逻辑直接跳过，内核线程创建速度远快于用户进程fork，这是原因之一。
4.2 dup_task_struct与内核栈分配
继续往下走，核心步骤是dup_task_struct。这一步要为新任务分配task_struct本体、thread_info以及内核栈。
老内核里thread_info常常内嵌在task_struct中，内核栈则单独分配。随着CONFIG_THREAD_INFO_IN_TASK的普及，很多架构把thread_info并进了task_struct，内核栈改由CONFIG_VMAP_STACK机制从vmalloc区域分配。这个变化影响很大：如果内核栈从vmalloc分配，虚拟地址空间更大，栈溢出检测更从容，但也意味着fork时分配栈可能因为vmalloc空间不足而失败。
dup_task_struct这一步本质上做了一次浅拷贝：把父进程的task_struct内容复制一份，再重置那些必须是新任务独立的字段，比如tasks链表节点、pid相关结构、各种锁的初始状态等。这里没有任何用户态数据的复制，性能开销主要取决于结构体大小和架构相关字段的初始化。
4.3 共享与复制资源的顺序讲究
copy_process中段是一连串copy_*函数，它们负责决定哪些资源共享、哪些资源复制。典型顺序大约是：copy_sighand、copy_signal、copy_files、copy_fs、copy_namespaces、copy_mm、copy_io、copy_thread等。
为什么顺序有讲究？因为后续步骤可能会失败，而已经复制成功的部分需要相应清理。比如先复制信号相关结构，再复制文件表，如果文件表复制失败，内核要能安全回滚信号结构的引用计数。这个顺序是经过长时间调试稳定下来的，不是随便排的。
CLONE_FILES控制是否共享文件描述符表，CLONE_FS控制是否共享根目录和当前工作目录，CLONE_SIGHAND和CLONE_SIGNAL控制信号处理与信号状态共享。线程组至少要共享文件表、文件系统信息、信号处理函数和内存空间，这些标志位在线程创建时被glibc一次性设置好。
copy_mm是用户态fork成本的主要来源。好消息是它也不会真的复制全部物理内存。在CLONE_VM未设置时，copy_mm会调用dup_mm，为新进程建立一份页表副本，并让所有页面标记为只读且可写时复制。也就是说，fork之后父子进程的虚拟地址空间内容都一样，但实际物理页是共享的，直到某一方写入才触发缺页中断复制页面。这就是为什么现代操作系统的fork()比大多数人想象中轻量。
4.4 sched_fork与调度实体初始化
copy_process还会调用sched_fork，为新任务的调度器相关状态做初始化。这里做的事包括：新任务初始优先级继承自父进程、task_struct里的se字段重新初始化、cgroup的调度组信息关联等。新任务还没有被唤醒，状态被标记为TASK_NEW，这是后续wake_up_new_task将要处理的关键状态。
很多初学者会问：为什么copy_process里不直接把新进程唤醒，而要等回到kernel_clone里再唤醒？原因是copy_process存在失败可能，在它内部只负责把新任务准备好并挂入进程链表，成功与否在返回后才知道。把唤醒动作放在kernel_clone的成功路径上，逻辑更清晰，也方便ptrace在子进程真正运行前介入。
4.5 alloc_pid与进程号分配
新任务必须有自己的PID。alloc_pid负责分配struct pid以及各个PID命名空间层级的编号。如果启用了多级PID命名空间，还需要为每一层命名空间分配一个对应的nr值。alloc_pid失败会返回-EAGAIN，这直接影响用户态fork的errno，后面排查部分会展开讲。
分配完PID后，新任务的pid、tgid等字段会被填充。对于线程创建，tgid继承自父进程的线程组ID，pid则是新线程自己的编号。这就是同一个线程组里所有线程的tgid相同、pid各异的底层来源。
4.6 vfork_done的巧思
kernel_clone开头那段代码里有一个容易被忽略的completion变量：
if (clone_flags & CLONE_VFORK) init_completion(&vfork);这个vfork对象实际上是放在kernel_clone的栈上的。如果设置了CLONE_VFORK，copy_process末尾会把p->vfork_done指向父进程栈上的这个completion，同时执行get_task_struct(p)防止子进程过早释放。
子进程在执行execve()或者退出时，内核会调用mm_release()，其中会complete(vfork_done)，把父进程从wait_for_completion_killable(&vfork)里唤醒。这样vfork就实现了“子进程先运行，父进程阻塞等待”的语义。vfork这名字虽然看着像“几乎不复制”，但内核实现上借助了复制与共享的组合，本质是等待机制的同步。
4.7 尾声的cgroup与安全钩子
现代内核在copy_process尾部还会调用cgroup_can_fork、cgroup_post_fork以及security_task_fork之类的钩子。这些钩子在容器场景里非常关键，比如cgroup的pids控制器就可以在cgroup_can_fork阶段直接拒绝新的进程创建，返回-EAGAIN。这也就是为什么你即使没到系统全局的pid_max限制，也可能因为cgroup限制而fork失败。
从整体看，copy_process基本架构是“先浅复制，再逐资源决定共享或深复制，最后挂链表加钩子”。它是对老do_fork实现思路的延续，但在5.x被整理得更结构化。
5. copy_thread与ret_from_fork的入口魔法
进程创建不是把task_struct复制完就完事，新任务必须有一个明确的执行入口。这个入口的设定发生在copy_thread函数中。虽然名字带copy，但它实际上是在构造新任务的初始寄存器上下文。
对于用户态进程，copy_thread会把父进程当前的pt_regs复制到新任务的内核栈，然后把用户态的系统调用返回值寄存器改成0。这正是fork语义的底层实现：父进程从内核返回到用户态时，系统调用返回值是新子进程的PID；子进程被切换调度后，从同一个位置返回用户态时，看到的是0。
对于内核线程，情况完全不同。copy_thread检测到PF_KTHREAD标志后，不再复制父进程的寄存器，而是清零寄存器上下文，并把fn和fn_arg放到特定位置，将新任务的thread.sp指向一个统一的启动路径。这个路径在x86_64上叫ret_from_fork。
ret_from_fork从字面理解就是“从fork返回”，但它面对的任务类型不同，后续路径也不同。对于普通用户进程，它负责调用schedule_tail完成调度器收尾，然后切换回用户态；对于内核线程，它从栈上取出fn和fn_arg，跳转到fn(arg)执行，等fn返回后再调用do_exit清理线程栈。
这个设计非常精妙。内核线程不自己负责退出清理，它的函数fn只要正常返回，ret_from_fork路径会自动兜底。很多写内核线程模块的开发者容易忽略这一点，以为自己得在fn里手动do_exit，其实不需要，但如果确实需要带退出码退出，也可以显式调用do_exit(code)。
6. 实机观察kernel_clone：ftrace、kprobe与内核模块
理论讲了这么多，不亲手观察一遍，总觉得隔了一层。如果是5.x内核，下面这几招都可以直接在自己机器上试。
6.1 用ftrace看kernel_clone调用树
最直观的方式是function graph跟踪。挂载tracefs并把kernel_clone设为跟踪目标：
mount -t tracefs tracefs /sys/kernel/tracing echo kernel_clone > /sys/kernel/tracing/set_graph_function echo function_graph > /sys/kernel/tracing/current_tracer echo 1 > /sys/kernel/tracing/tracing_on然后在另一个终端随便执行一个会fork的命令，比如bash -c "echo hello"。过一会儿来看跟踪结果：
cat /sys/kernel/tracing/trace | grep -A 80 "kernel_clone"你会看到kernel_clone调用了copy_process，而copy_process内部又展开一系列子调用，dup_task_struct、copy_files、copy_mm、alloc_pid等全都清晰可见。这比单纯读源码更能建立整体直觉。
如果你用的一些发行版默认没开CONFIG_FTRACE或者符号不可见，可以试试先查一下：
cat /sys/kernel/tracing/available_filter_functions | grep kernel_clone有输出就能挂。
6.2 用kprobe事件直接抓参数
知道kernel_clone第一个参数是struct kernel_clone_args *后，可以在x86_64上用kprobe抓它的参数。这里有个小坑：flags在结构体的第一个字段，所以首先可以试试直接取args->flags。不过tracefs的kprobe语法对结构体偏移不够友好，更省事的做法是直接用bpftrace：
bpftrace -e 'kprobe:kernel_clone { printf("comm=%s flags=0x%llx fn=%p\n", comm, ((struct kernel_clone_args *)arg0)->flags, ((struct kernel_clone_args *)arg0)->fn); }'如果内核开了BTF，这种结构体字段访问可以直接工作。没开BTF，就用最朴素的方案，只打印arg0指针值：
bpftrace -e 'kprobe:kernel_clone { printf("kernel_clone called from %s, args=%p\n", comm, arg0); }'注意，普通用户需要root权限，或者给bpftrace配置capability。内核函数名是否可见也受符号表影响，但kernel_clone是全局符号，大多数内核配置下都能抓到。
6.3 用一个最小内核模块验证kernel_thread
如果只是静态读源码，对fn路径的理解始终有点抽象。我习惯写一个最简模块来验证：
// SPDX-License-Identifier: GPL-2.0 #include <linux/module.h> #include <linux/kthread.h> #include <linux/delay.h> static int test_fn(void *data) { pr_info("test kernel thread running, pid=%d mm=%p\n", current->pid, current->mm); return 0; } static int __init test_init(void) { pid_t pid; pr_info("module init, calling kernel_thread\n"); pid = kernel_thread(test_fn, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGHAND); pr_info("kernel_thread returned pid=%d\n", pid); return 0; } static void __exit test_exit(void) { pr_info("module exit\n"); } module_init(test_init); module_exit(test_exit); MODULE_LICENSE("GPL");编译加载后看dmesg，你应该会看到内核线程打印出来的pid是一个新分配的内核线程号，mm为NULL。这个实验能帮你确认PF_KTHREAD路径下mm确实为空。注意，模块里不需要额外做线程清理，test_fn返回后内核会自动走do_exit。
7. 常见问题与排查实录
这类代码的坑往往出现在真实场景里。我挑几个自己或同行实际踩过的问题，按现象、原因、排查顺序来写。
7.1 fork频繁返回EAGAIN
最典型的故障表现是应用层fork()失败，errno为EAGAIN，日志里能看到Resource temporarily unavailable。
第一反应是看系统级限制：cat /proc/sys/kernel/threads-max、cat /proc/sys/kernel/pid_max、ulimit -u。但很多情况下这三个值都正常，问题出在cgroup的pids控制器上。容器环境下，/sys/fs/cgroup/pids.max可能设了上限，一旦达到上限，cgroup_can_fork会直接拒绝新任务。copy_process里alloc_pid失败、dup_task_struct失败、cgroup限制、RLIMIT_NPROC限制，都会映射到-EAGAIN。
排查时不要只看应用层日志，先dmesg -T翻一遍内核日志。如果看到fork: Cannot allocate memory字样，十有八九是内核栈或task_struct分配问题，继续看有没有vmalloc: allocation failure。如果什么内核日志都没有，那多半是cgroup或rlimit这类用户可配置的限制。
7.2 CONFIG_VMAP_STACK与内核栈分配失败
5.x内核普遍启用了CONFIG_VMAP_STACK，新任务的内核栈从vmalloc区域分配。vmalloc虽然能分配比直接映射区更大的虚拟地址空间，但它不是无限的。一个典型的故障是：线程数量达到数万级别时，新线程创建突然失败，dmesg里出现vmalloc: allocation failure。
原因往往不是物理内存不够，而是vmalloc虚拟地址空间耗尽或者碎片化。kernel_clone对新进程中dup_task_struct这一步返回-ENOMEM，用户态看到fork失败。这种情况下，解决办法是降低单机线程密度，或者检查是否有内核态内存泄漏反复申请大块vmalloc区域。用grep Vmalloc /proc/meminfo可以大致估算使用水线。
7.3 kernel_thread回调里的操作限制
写内核线程模块，最常踩的坑是在fn函数里直接操作用户态内存。内核线程没有mm，current->mm是空的，copy_to_user/copy_from_user这类接口会直接失败。正确的做法是临时借用目标进程的mm：先get_task_mm拿引用，再kthread_use_mm绑定，用完kthread_unuse_mm并mmput释放。
还有一个细节：kernel_thread创建的线程和父内核线程之间文件表、文件系统信息、信号处理是否共享，完全取决于调用时传的flags。常见习惯是传CLONE_FS | CLONE_FILES | CLONE_SIGHAND，让内核线程随父线程共享这些资源。如果什么都不传，新线程会有一整套独立副本，虽然也能工作，但可能带来意外的资源开销和语义差别。
7.4 ptrace事件与信号设置的关联
调试器有时会把fork事件报告成clone事件，或者反过来。原因藏在kernel_clone对trace类型的选择逻辑里：
if (!(clone_flags & CLONE_UNTRACED)) { if (clone_flags & CLONE_VFORK) trace = PTRACE_EVENT_VFORK; else if (args->exit_signal != SIGCHLD) trace = PTRACE_EVENT_CLONE; else trace = PTRACE_EVENT_FORK; }这里判断标准不是“是不是线程”，而是exit_signal是否等于SIGCHLD。如果调用者用clone创建了一个exit_signal不是SIGCHLD的进程，ptrace会把它当作clone事件处理。反过来，如果一个线程创建时带了SIGCHLD，它会被报告成fork事件。遇到这类现象，回来看这个判断逻辑就能对号入座。
7.5 clone3与传统clone的兼容问题
某些glibc版本会优先尝试clone3，只有在内核返回ENOSYS时才回退到clone。如果你自编译内核时把clone3相关配置关了，或者用了老一代内核，用户态应用可能偶发创建进程失败但也可能完全无感，取决于glibc的fallback覆盖是否完整。排查时可以用strace -f -e trace=clone,clone3直接看应用实际发起了哪个系统调用，避免在内核日志里瞎猜。
8. 一点实操心得
最后分享一个我个人用起来很顺手的技巧。如果你怀疑某次进程创建卡在了kernel_clone的某一段，又不想重新编译内核加日志，那就用ftrace的function_graph同时挂上kernel_clone和copy_process，再复现一次现场。不要急着去翻源码，先用工具把实际调用路径固定下来。对比成功和失败两份trace的差异点，往往一眼就能看出是卡在copy_mm、alloc_pid还是cgroup钩子上。
另一个体会是，读这种大函数时千万不要从头到尾顺序硬啃。先抓住三个关键分支：args->fn是否为空、CLONE_VFORK是否设置、CLONE_THREAD和CLONE_SIGHAND等组合标志的共享关系，剩下的细节再顺着调用图展开。把这几条主线理清后，copy_process那几百行代码就变得有脉络可循。
