为何Userfaultfd需先注册内存页才能接收EVENT_FORK事件？

1. 必须注册有效虚拟页才能收到fork事件的原因 #

userfaultfd 的 EVENT_FORK 事件触发的核心前提是：该userfaultfd实例已经与当前进程的地址空间（内核中的mm_struct结构）建立关联。而这种关联只有在通过UFFIO_REGISTER（对应代码中的uffd.register）成功注册至少一块有效的虚拟内存区域后才会完成。

内核逻辑中，未注册任何有效内存区域的userfaultfd实例不会被绑定到进程的地址空间结构上。当进程执行fork时，内核只会遍历那些已经与当前进程mm_struct绑定的userfaultfd实例，生成并发送EVENT_FORK事件。如果没有注册有效区域，内核根本不会感知到该userfaultfd的存在，自然不会触发事件。

无效注册（比如空指针）会因为内存区域非法导致注册失败，同样无法完成userfaultfd与进程地址空间的绑定，因此也收不到事件。

2. fork调用阻塞至主线程执行read_event的原因 #

当userfaultfd注册了有效区域且启用了EVENT_FORK时，内核在处理fork系统调用的过程中，会暂停fork的完成流程，直到父进程读取到EVENT_FORK事件。这是内核的同步设计：目的是让父进程有机会在子进程开始执行任何代码前，处理子进程内存页的相关逻辑（比如设置子进程内存的userfaultfd规则）。

你的代码中uffd创建时设置了non_blocking(false)，所以read_event是阻塞式读取，只有当主线程读取到事件后，fork调用的父进程分支才会继续执行，这就导致了输出中先打印Event: Fork...，再打印Waiting for child的顺序。

3. 子进程自身fork时无法收到事件的原因 #

子进程通过fork创建后，会复制父进程的地址空间和文件描述符（包括uffd），但子进程的mm_struct并没有与继承来的uffd实例建立关联——这种地址空间与userfaultfd的绑定关系是进程独有的，不会随fork复制。

因此，当子进程再次执行fork时，内核不会遍历到该uffd（因为子进程的mm_struct上没有绑定它），自然不会向父进程的uffd发送事件。如果需要捕获子进程的fork行为，你需要在子进程中重新调用uffd.register，将该uffd与子进程的地址空间绑定，但这还需要确保子进程拥有对应的权限（比如CAP_SYS_PTRACE）。

内容的提问来源于stack exchange，提问作者Filipe Rodrigues