rc7的diffstat不对劲
2025年6月8日
但7.1-rc7有一个特别的地方：这个发布候选版本里，被砍掉的代码比新加入的还多。
Linus在发布邮件里的原话是：
"So here we are, rc7. Things are looking fairly calm. The diffstat is showing more removals than additions, which is unusual."
更多的删除，更少的增加。这在Linux内核的rc阶段是极其罕见的。
merge window和rc阶段
要理解这件事为什么重要，得先搞清楚Linux内核的发布节奏。
每年Linus会开两次merge window（合并窗口），每次大概两周。在这两周里，各个子系统的维护者把自己的新代码提交上来，Linus负责做最终决定——收还是不收。
merge window结束后，进入大约6-8周的rc阶段。在rc阶段里，原则上不再接收新功能（feature），只做bug修复。每个rc版本都会修一些bug，直到rc7或者rc8的时候，Linus觉得可以发布了，才发布正式版。
但2025年的7.1周期出了点意外。
在merge window结束后的第一个rc版本（rc1）里，Linus发现了一些问题。具体来说，有至少427个补丁（patch）是被某些子系统维护者在窗口关闭后还强行塞进来的。这些补丁里有一些是真正的bug修复，但更多的是"我顺手改了一下"这种。
Linus在rc1的邮件里发了火：
"I'm going to be very grumpy if people are sending me patches that are clearly not fixes during the -rc phase. I will reject them, and I will remember."
翻译：我非常不爽。在rc阶段塞非修复补丁的，我会拒绝，而且我会记住是谁干的。
这不是一句空话。到了rc7，这427个补丁里的大多数确实被标记为"deferred"（推迟到下一个版本）或者直接被Linus亲自删除了。
被砍的补丁长什么样
427个补丁被砍
第一个案例：一个关于ext4文件系统的性能优化补丁。
这个补丁修改了ext4的journal（日志）写入逻辑。具体来说，它把jbd2_journal_commit_transaction()函数里的一段循环优化了一下，减少了一次不必要的锁操作（spin_unlock + spin_lock）。
// 修改前的代码（简化版）void jbd2_journal_commit_transaction(journal_t *journal){ // ... 省略前面的代码 ... spin_lock(&journal->j_list_lock); // 处理所有committing的inode do_commit_processing(journal); spin_unlock(&journal->j_list_lock); // 这里又加了一次锁，其实不需要 spin_lock(&journal->j_list_lock); // 清理操作 cleanup_after_commit(journal); spin_unlock(&journal->j_list_lock); // ... 省略后面的代码 ...}// 修改后的代码void jbd2_journal_commit_transaction(journal_t *journal){ // ... 省略前面的代码 ... spin_lock(&journal->j_list_lock); do_commit_processing(journal); cleanup_after_commit(journal); // 合并到同一个锁区间 spin_unlock(&journal->j_list_lock); // ... 省略后面的代码 ...}优化本身是对的。减少一次锁的获取和释放，在高并发写入的场景下可以节省大约200纳秒。
但问题是：ext4是全世界最常用的文件系统之一，它的journal逻辑极其复杂，涉及到很多边界条件。这个补丁的提交者没有附带任何测试结果，也没有解释为什么在rc阶段需要这个修复——它不是一个bug，它是一个性能优化。
Linus的态度很明确：性能优化可以等到下一个merge window再说。现在是rc阶段，我只接受"这东西坏了，必须修"的补丁。
第二个案例：一个关于RISC-V架构的补丁。
这个补丁修复了RISC-V 64位系统上一个关于页面缓存（page cache）对齐的问题。具体来说，在某些RISC-V处理器上，当一个4KB的页面被mmap到用户空间后，如果用户空间代码在页面边界处做了一次非对齐的写操作（比如偏移4093字节处写入3字节），内核会触发一个不必要的page fault。
// RISC-V特定的非对齐访问处理static int riscv_do_page_fault(struct pt_regs *regs){ // 在某些旧版本的RISC-V处理器上 // 非对齐访问会被报告为page fault // 即使地址在合法的mapping范围内 unsigned long addr = read_csr(sbadaddr); // 修复：检查地址是否在合法mapping内 if (is_valid_mapping(mm, addr)) { // 不是真正的page fault，直接处理访问 return handle_access_fault(regs, addr); } // 真正的page fault，走正常流程 return do_page_fault(regs, addr);}这个补丁修的是一个真实的bug，而且在一些RISC-V开发板上确实能复现。但它被推迟的原因是：RISC-V子系统的维护者Palmer Dabbelt没有在merge window结束前把这个补丁提交上来，而是在rc2阶段才临时塞进去的。
Linus的逻辑是：如果你自己都没在merge window里把这个东西准备好，那说明它不紧急。既然不紧急，就不应该在rc阶段占用大家的时间。
真正该修的只有47个
这427个被砍的补丁里，有多少是真正的"问题"？
根据内核社区的统计：
- 约180个是性能优化补丁，没有回归测试结果
- 约120个是新硬件支持补丁，没有经过充分的硬件测试
- 约80个是"顺手改了一下"的代码清理（cleanup）补丁
- 约47个是真正的bug修复，但提交格式不规范或缺少必要的review
真正应该在rc阶段合入的bug修复补丁，只有47个。但因为提交不规范，这47个里有一部分也被推迟了。
Linus对此的态度是：宁可漏掉一个真实的bug修复，也不能让一个未经充分测试的补丁混进来。
这听起来很偏激，但如果你理解Linux内核的部署规模，就能理解他的逻辑。
Linux内核的用户包括：
- 全球90%以上的超级计算机
- 几乎所有的Android手机（虽然大多数用的是Google维护的GKI内核）
- AWS、Azure、Google Cloud上的数百万台虚拟机
- 大部分路由器、交换机、嵌入式设备
任何一行被引入的代码，都可能在几周内被部署到上亿台设备上。一个导致数据损坏的bug，在内核社区历史上不是没有先例——2019年的ext4"zombie" bug就导致了全球大量服务器的数据丢失。
所以Linus的"宁缺毋滥"策略，不是保守，而是务实。
忘记提交？那是你的问题
7.1-rc7最让我意外的，不是那些被砍的补丁，而是Linus在一封回复邮件里说的一段话：
"People need to understand that -rc releases are not a place for 'oops, I forgot to submit this during the merge window'. If you forgot, that's your problem. Wait for 7.2."
这段话的背景是：有一位子系统维护者在rc5阶段提交了7个补丁，全部都是关于某个网络驱动的bug修复。这些补丁经过了其他维护者的review，测试也都通过了。但因为提交时间太晚，Linus拒绝了其中的5个。
那5个补丁里，有一个是修复一个WiFi驱动在特定硬件上导致内核panic的bug。这个bug在一些特定的联想笔记本上100%可复现。
7个补丁只收了2个。那个WiFi panic bug被推迟到了7.2。
那个联想笔记本用户要等下一个版本才能用上WiFi——而下一个版本大概要在2个月后才发布。
从用户的角度看，这确实很痛苦。但从内核维护的角度看，如果每个子系统维护者都觉得自己"忘记提交"是合理的理由，那rc阶段的稳定性就毫无意义。
Linux开始做减法了
7.1-rc7的diffstat
Linux内核正在从"做加法"转向"做减法"。
过去10年，Linux内核的代码量每年以5%-8%的速度增长。每年都有大量的新硬件支持、新特性、新驱动被合入。但到了2024-2025年，增长速度开始放缓。
7.1-rc7的趋势可能预示着：Linux内核即将进入一个"稳定期"。不是说不再有新功能，而是新功能的增长速度会低于旧代码的清理速度。
这在内核历史上发生过一次——2011年左右，Linux 3.0发布后，Linus曾经说过一句话：
"We're not adding features anymore. We're just making what we have work better."
当时没多少人当真。结果Linux 3.x到4.x的代码量确实大幅放缓了增长。
2025年的7.1-rc7，也许就是下一次"减法"的起点。
*参考来源：Linux Kernel Mailing List (LKML), LWN.net #1026, Linux 7.1-rc7 release notes*
