Linux 7.0 重磅更新：详解 nullfs 如何重塑根文件系统挂载与内核线程隔离

在即将发布的 Linux 7.0 内核中，最引入注目的早期合并之一便是 nullfs。

简单来说，nullfs 是一个绝对为空的文件系统，它不支持创建任何文件，也不存储任何数据。你可能会问：内核里加入一个"一无用处"的文件系统到底图什么？

事实上，nullfs 的引入是为了解决 Linux 启动过程中困扰开发者多年的"优雅性"问题，并为内核安全性（Hardening）打下基础。

在 Linux 引导过程中，定位并挂载根文件系统（rootfs）是一项极其复杂的任务。这通常涉及解析配置文件、组建 RAID 卷、甚至通过网络获取数据。

为了完成这些操作，内核首先会挂载一个临时的根文件系统------initramfs。它随内核镜像一起加载，包含必要的驱动和工具。

按照标准逻辑，当真正的磁盘文件系统准备好后，我们应该使用 pivot_root() 系统调用将临时根替换为永久根。但问题在于：rootfs（初始 ramfs）无法被 pivot_root()。

当前的通用做法（如 switch_root 脚本）包含以下繁琐步骤：

在 7.0 中，内核将整个文件系统树建立在 nullfs 之上。

新逻辑： 临时根和永久根都挂载在 nullfs 这个"空基座"上。
结果： 由于 nullfs 才是真正的底层基座，pivot_root() 终于可以正常工作，将永久根直接置于挂载栈下方并卸载临时根。整个过程更加原生、简洁。

除了简化挂载流程，nullfs 的另一个大招是增强内核线程（Kernel Threads）的隔离性。

在 Linux 系统中，最早创建的两个进程是 init（用户态祖先）和 kthreadd（内核态祖先）。

以往，这两个进程共享同一个初始 fs_struct（文件系统结构表）。这意味着：

由 Christian Brauner 提出的方案是：让内核线程运行在 nullfs 实例中。

彻底断链： 内核线程的根目录被设置为 nullfs。由于 nullfs 无法存放文件，内核线程默认失去对文件系统的所有访问权限。
按需授权： 只有确实需要访问文件系统的线程（如处理固件加载、Core Dump 或 Unix 域套接字的线程），才通过新引入的 scoped_with_init_fs() 宏临时获得权限。

// 只有在作用域内，内核线程才具备文件系统访问能力
scoped_with_init_fs() {
/* 执行必要的文件系统操作，如加载固件 */
}

这种"最小权限原则"显著提升了内核的稳健性，防止内核线程意外干扰用户态的 init 进程。

这项改动触及了内核最底层的逻辑，其实现者 Christian Brauner 对此表现得非常坦诚：

"这主意疯吗？疯。可能会出 Bug 吗？极有可能。但它至少能跑（It boots）。"

尽管改动巨大且充满挑战，但社区对此方向普遍持支持态度。这种对深层代码的重构，标志着 Linux 在追求更现代、更安全的架构上从未停步。

nullfs 的引入不仅仅是增加了一个文件系统类型，它是对 Linux 引导架构的一次微调，更是对内核线程安全边界的一次重划。