Linux 7.1:530 位首次贡献者,冲击着有限的维护者体系

530 位首次贡献者，再加上 AI，他们写出了能够启动数十亿台机器的代码。那些疲惫不堪为数不多的维护者，必须逐一审查这些代码，他们还能跟得上吗？

他们接触的那些代码，正在启动你的手机、你的银行系统，以及几乎整个云基础设施。在它们发布之前必须逐行审查的人，时间已经不够用了。

Linux 内核依赖有人在代码进入数十亿台机器之前进行阅读审查。静态扫描工具能捕捉一部分 bug，但遗漏的部分，就落在那些对某个子系统足够熟悉的维护者身上：比如看到文件系统的一段补丁，就能判断它是否安全。

这样的人无法扩展，只有寥寥数人，他们已经很疲惫。

Linux 7.1 于 2026 年 6 月 14 日发布。它的 git 历史记录显示，这是迄今为止首次贡献者最多的一个周期。

大多数新贡献者借助了AI编程工具，不少人集中修补文件共享相关的核心代码；本次版本最重要的功能，出自一位内核维护者之手。

AI 赋能的数字初吻（Digital First-Time Kiss With AI）

我曾在数字健康、电信和流媒体领域领导过 14 个平台的工程团队。一直以来的瓶颈是，找到那种能同时理解多个子系统的资深工程师，并判断一个改动是否会悄悄破坏另一个系统。再招十个初级工程师，只会让这位工程师更忙、更被淹没，而不是更轻松。

而内核刚刚在行星级规模上运行了一次这样的实验。

Linux 每一次变更都会留下永久痕迹，git 历史就是项目的日志簿，完整记录了谁在何时改了什么，7.1 这个周期在其中留下了密密麻麻的记录。

本次发布共接收 15,849 个 changeset。一个 changeset 是对代码的自包含修改（self-contained edit，一个完整、独立、可以单独审查和合并的代码修改单元），这个统计还不包括 merge commit（它们只是把一个分支的工作合并到另一个分支）。大约有 2,479 名开发者触碰了代码树——也就是所有人共同构建的那份源码副本。此前从未有过如此多的参与者。上一个最高纪录是 7.0 版本的 2,362 人，再之前是 6.19 创下的纪录。这个数字几乎每个周期都在上升。

然后是首次贡献者。在这 2,479 名开发者中，有 530 人在这个周期之前从未向内核贡献过代码。

相比 7.0 的 489 人，这是进一步的增长，这种陡峭上升趋势已经持续了一年多。一个名字从未出现在内核提交记录的人，对内核写下补丁，并让它驱动全球绝大多数服务器。在两个月内，有 530 人做了这样的事情。

或者至少，是我们认为所有新贡献者都是人类的两个月内……

只有诚实的人会留下痕迹

到 2026 年春季，内核采纳了一项关于“使用代码辅助工具编写代码”的政策。该规则记录在 docs.kernel.org 上，措辞非常直接，强调责任归属。

当 AI 工具参与生成补丁时，提交记录必须包含一行 “Assisted-by”，注明所使用的工具。但 AI 不能签署代码。只有人类可以合法地确认 Developer Certificate of Origin（开发者来源证明），也就是那句“这是我写的，或者我有权提交它”。提交补丁的人必须对其完全负责，包括模型生成的每一行代码。

在 7.0 中，内核记录了 31 个带有该标签的提交。在 7.1 中，这个数字是 299。

这几乎是一个周期内增长了十倍。真实数字很可能更高，因为这一标记是自愿声明的，你也可以在 LLM 级别关闭它。因此 299 只是下限，而不是上限。真实值可能高出多少无法得知，因为未披露工具的本质，就是不留下痕迹。

git 历史还揭示了本周期最繁忙的新贡献者：一个开发者在二十多个互不相关的子系统中提交了 60 个 commit，从 SCSI 存储驱动、蓝牙，到 io_uring、RDMA，以及 AMD 图形驱动。大多数提交都带有 Assisted-by 标签。其中最大的一块集中在 SMB 文件系统——也就是 Windows 文件共享的那部分代码。

这二十多个子系统由不同维护者负责，一个子系统的 bug 经验不能帮助你理解另一个子系统。理解 SCSI 不会帮助你审查蓝牙或图形驱动。而 AI 工具可以为任何一个子系统生成“看起来合理”的补丁。你不需要在 SCSI 领域积累多年经验才能提交 SCSI 补丁。

贡献者节省了学习子系统的数年时间，但维护者必须阅读请求并签字负责。运行在数十亿台机器的软件安全，最终取决于少数审查者能否跟得上节奏。

审查到底在做什么

某个维护者在周二打开邮箱，发现有 40 个补丁在等待审查。自动化系统已经做过初步筛查：内核测试机器人在一百多种配置下编译了这些补丁，尝试启动系统，并在失败时通知作者；静态分析工具也标出了明显错误。这些确实能过滤很多问题，但它们无法判断一个改动是否真正安全。

其中一个补丁涉及 SMB 文件系统——Linux 用它读取和写入 Windows 共享文件。维护者开始阅读：是否存在恶意构造的网络包绕过缓冲区边界？错误路径是否泄露锁？它与该代码历史上的 bug 有何关联？最终，他判断这个补丁可以安全合并，并为所有挂载远程共享的机器承担责任。

这个维护者，是一个每周用来审核代码的时间非常有限的人类。

现在，每个审查者都要面对创纪录数量的补丁，许多由 AI 编写，审查者的数量并没有同步增长。

这就是这个发行版本的开放问题：补丁数量的增长超过了能够负责任地审查它们的人数增长。

如果“写代码”和“审查代码”之间的鸿沟让你和我一样担忧，可以留下你的看法，分享你所在团队如何处理 AI 生成的代码审查。这已经不仅仅是内核的问题了。

Torvalds 称之为“复活”

有一个人完成了Linux 7.1最大的功能改进。

Namjae Jeon 用大约四年时间开发了一个新的NTFS 驱动，可以以原生速度读写 Windows 磁盘，基于 iomap 路径——这是已经支撑 XFS 的高性能 I/O 层。Linus Torvalds 称这次合并为“NTFS 复活”。它计划取代老旧的 ntfs3 以及用户态 ntfs-3g 路径，不过 ntfs3 仍是默认驱动。

在实际使用中，系统管理员插入一块 12TB 的 Windows 硬盘，挂载后开始恢复数据。内核直接写入磁盘，而不是通过用户态转换逐块处理。据 Jeon 称，多线程写入吞吐量大约翻倍（这是他自己的数据，并非独立基准测试）。原本需要一整夜的恢复任务，在午饭前就能完成。

Jeon 不只做 NTFS。他还编写了 in-kernel exFAT 驱动，并开发了 ksmbd——内核 SMB 服务器，前面那些新贡献者修补的正是这个子系统。

Jeon 同时维护 NTFS、exFAT 和 SMB server：两个文件系统，以及一个每天都会被基础设施使用的网络文件服务。但他不是单独完成的。每个系统通常只有两位维护者，Jeon 每次都是其中之一，负责审查这些代码的人数就是这么少。

发布的其余部分则填补了其他改进：Intel FRED（现代中断与系统调用入口机制）在支持的 x86_64 上默认启用，降低 Panther Lake 及后续架构的延迟；NFS server 增加了对客户端文件引用 token 的签名能力，可检测伪造请求；exFAT（SD 卡与 U 盘常用文件系统）新增 fallocate；NVIDIA 的 nova 驱动推进 Rust 代码，加入 Turing 支持以及 GPU System Processor（GSP）强化；Steam Deck OLED 用户终于获得可用音频支持。

本版本还移除了超过 14 万行废弃代码；上一周期启动的清理行动，是因为 AI 生成的未使用驱动报告过多，已经压垮维护者。

Rust 在 7.0 已经稳定，这次不是 Rust 的“到来”，而是持续的渐进式进展，加上一个“复活”的文件系统。

同一个漏洞，出现在你的手机和云端

Linux 7.1 于 2026 年 6 月 14 日发布。第一个稳定小版本 7.1.1 在 6 月 19 日发布，由 Greg Kroah-Hartman 签名。

只隔五天……

它是一个只包含修复的小版本，包含了大量补丁，其中一个已经被评为严重级别。

该补丁修复的是 CVE-2025–10263，这是一个 CVSS 评分 9.1 的高危漏洞。漏洞存在于 ARM 的核心设计中，ARM 架构支撑着全球大多数手机以及越来越多的云服务器。ARM 本身不生产芯片，像高通这样的芯片制造商授权其设计并制造实际硬件。大多数 Android 手机都运行基于 ARM 的高通芯片。

每个处理器核心都有自己的缓存用于加速，并记录程序可以访问哪些内存。当系统撤销某项权限时，会通知核心丢弃旧记录，并等待确认。但漏洞出现在这个“确认”机制中：核心可能在实际清除之前就报告已经清除。在这短暂窗口中，一个本应被阻止的写操作仍然发生。云服务器上不同客户共享同一物理机器并彼此隔离，这个漏洞可能让一个客户的代码穿透隔离层，访问本不应接触的内存，包括隔离其他客户的宿主系统。

这种问题无法通过硬件修复，只能靠软件：内核在受影响的核心上插入额外的 invalidate-and-barrier 指令。并且必须在已经紧张的维护审查链中，由稳定版本截止日前完成合并。

受影响的处理器包括一些最广泛使用的芯片，例如微软 Azure Cobalt 100 和 NVIDIA Vera Olympus 核心，以及高端手机中的 Cortex-X 和 C1 核心。医院的云租户与普通用户的手机，可能共享同一个漏洞。

同一版本还修复了另一个没有编号的 bug：一个精心构造的网络包可以冻结内核中负责向运行程序发送信号的部分。两个执行路径相互等待，导致系统停滞。维护者在静态阅读代码时无法发现问题，因为它只在运行时、特定网络输入下出现。因此Linux内核不只依靠人工阅读代码，还依靠自动化工具持续向已发布代码投放异常输入。当某个输入触发崩溃时，修复会被回补到仍在维护的旧版本——大多数机器实际运行的就是这些版本。

7.1 的提交数据展示了审查系统承受的压力，任何人都可以拉取 git 历史计算这种压力。

530 个新贡献者本周期提交了补丁……你希望审查它的人，是一个在该子系统深耕十年的维护者，还是一个 LLM？后者可能不比一只醉酒的猴子更可靠。

答案取决于：为数不多的维护者在已经排满的工作周里，是否还有时间。

下一次发布的数字增长，你怎么看？

参考

https://canartuc.medium.com/linux-7-1-530-strangers-against-a-handful-of-maintainers-who-cant-keep-up-a0becf545f18