Linux 7.2被叫做史上第二忙的内核,这说法经得起核吗?

2026年6月28日，Linus关掉了Linux 7.2的合并窗口，发出7.2-rc1。LWN当天数了一遍进主线的东西：13412个非合并提交。这个数字后来被反复引用，成了"史上第二忙"这个说法的底座。

往后是六周常规的rc周期。8月16日夜里，7.2打上标签。我去kernel.org的releases.json核过，mainline那行写着7.2，发布日期2026-08-16，GitHub上v7.2标签的提交时间是2026-08-16T21:32:26Z。有点乱的是，LWN统计稿里写的是"8月17日"，Igalia汇总博客挂的是8月19日——一个是时区差，一个是发文日。不先对齐，一篇稿里能冒出三个"发布日"。

Linus在发布邮件里的原话是，最后这一周"又一次比我希望的要大"，然后补一句：以"新常态"来说，要是为这个推迟发布，那大概永远不会有发布了。新常态指的是这两年靠AI工具扫代码、成批提上来的修复。7.2最后一周还带着几个挺晚的回退，最扎眼的是DRM调度那块。

那句"只输给6.7"，到底按什么口径？

Igalia的汇总把这轮形容成"史上最忙的之一，只被6.7超过"。我想核清楚的是：这句话按的是提交数，还是改动行数。

按提交数，LWN写得很直白：7.2合并窗口的13412个非合并提交，是6.7之后最忙的一次合并窗口，6.7当年那个数是15418。整周期口径下，6.7最后落在17284个非合并提交，到现在还是纪录。

我自己拿GitHub的compare接口交叉验证了一次。curl比v7.1和v7.2，返回里的total_commits是10000——这接口对超大diff会截断，10000就是天花板，真值拿不到，这点必须说明。但同一份返回里的ahead_by没被截：v7.1到v7.2是17833，同样方法拉v6.6到v6.7是18404。这口径把合并提交也算进去，绝对值跟LWN对不上，相对关系一致——7.2没超过6.7。

口径一换，结论就翻了。

6.7那17284个提交里，将近3000个是bcachefs带着自己的完整开发史一起并进来的，等于一次性把好几年历史倒进主线。扣掉这块，6.7的常规开发量约在14300上下。而LWN说7.2整周期给内核"加了将近60万行代码"，6.7当年长的是56.6万行。按行数算，7.2反而超过6.7。第二忙成不成立，看你数的是提交还是行。

这些数跟你有什么关系？影响的是更新节奏。内核越忙，晚期回退越多，发行版越不敢急着跟。7.2这批东西要落到你手上的机器，跟主线紧的发行版大概等下个版本，跑企业发行版或Debian稳定版的等一年多也正常。例外是已经在玩树莓派和掌上设备的那批人，这轮有几条改动直接冲着他们去，下面会说到。

缓存感知调度到底在解什么问题？

这轮被点名最多的新东西是cache-aware scheduling，缓存感知调度。要解的问题不复杂：多线程进程的线程之间常常读写同一批内存，调度器过去不知道这事，只按负载均衡把线程撒到不同CPU上，结果每个线程在自己的末级缓存里存了同一份数据的副本，谁改一下别人那份就作废，得重新从内存拿。缓存这时候不是在帮忙，是在互相拖。

新做法是让调度器尽量把共享数据的任务聚到同一个末级缓存域里。补丁最早出自Peter Zijlstra的RFC，后来由Intel的Chen Yu接着做，kernelnewbies的7.2页面上标注它直接进标准调度器，不需要单独开开关。

别急着期待性能。LWN讲这套补丁那篇里有段挺关键：唤醒时调度器会很快把任务往首选缓存域上聚，负载均衡又倾向于把它挪开，两股力方向相反，任务可能在缓存域之间来回弹。Zijlstra当时的说法是，这东西得先真的让工作负载变快才行。7.2里的它更像起点，不是已兑现的收益。

一个bug怎么能藏住14年？

7.2里我最想弄明白的不是调度，是futex那边修掉的一个老bug。Igalia的汇总只给了一句话：帮助设计并落地了一个14年老bug的解法，这个bug影响robust list机制，某些边缘情况下会造成数据损坏。

futex是内核给用户态做锁用的系统调用。robust list这套机制专管一个场景：进程拿着锁中途挂了，锁怎么办。内核得知道它握着哪几把，进程一死就替它松开，并给等锁的人打上"上一任持有者已经死了"的标记，否则别人永远等在那。为了让内核知道进程正在动哪把锁，用户态会先把锁的地址写进一个叫list_op_pending的指针。

问题出在解锁那一步。解锁和清掉list_op_pending是两个动作，不是原子的，中间留着一条窄缝。进程要是正好在这条缝里被强制退出，内核清理robust list时读到的就是一个已经不该用的指针；这时候另一个任务恰好把那块内存unmap了，就是一次use-after-free，内核往一块不再属于它的内存里写东西。André Almeida给LKML发的复现程序打出来的是一行"Memory was corrupted by the kernel"，后面跟着两个对不上的数值。

它能藏这么久，原因就在那条缝上。触发它得有三件事在极短时间内凑齐：进程恰好在解锁和清指针之间被杀，锁所在的内存恰好这个当口被解除映射，这段内存还得被别的东西复用。日常跑几乎撞不上，想写测试稳定复现也难。

更实际的原因是，这东西早有人报过，只是一直没人动。Almeida在补丁里引的是glibc bugzilla的14485号，标题叫"robust mutex解锁中的文件损坏竞态"，报告人Carlos O'Donell，2012年的事。2012到2026，正好14年。我今天想去sourceware看原始报告，被站点的反爬拦下了，两次都没进去，所以这条只能引Almeida在邮件里的转述，不算我亲眼看过原帖。

最后落地的是Thomas Gleixner一个14个补丁的系列，标题直白得可爱：futex: Address the robust futex unlock race for real——这回动真格地解决。思路分两半：有人等锁的争用情况，内核给一个把解锁、清指针、唤醒合成一步的原子操作；没人争抢的常见情况，用户态改调vDSO里的函数，万一被信号打断，内核在信号处理里替它收尾。走vDSO不走系统调用，是因为无争用路径是锁的快路径，在那儿多一次系统调用的开销要命。Almeida那边补的是文档和自测。

这轮有什么真落到具体设备上了？

Igalia这轮的账面是82个提交署了他们的作者身份，另有74个review、13个acked、5个维护者签名。这堆里最有体感的是树莓派。V3D驱动过去的电源模型很粗：一探测到GPU就把时钟打开，整个驱动生命周期一直开着，GPU闲着照样耗电。7.2加了运行时电源管理，不干活时钟就能关。Maíra Canal拿外部功率计量过，100Hz采样、每场景跑300秒左右：带合成器空闲从3.300瓦降到3.192瓦，不带合成器从3.179瓦降到3.093瓦，跑glmark2基本没差。省的是零点一瓦上下，对一台常年插着电的派来说算白捡。

同一拨人还修了树莓派3上折磨RetroPie用户多年的GPU挂死，病根在GPU处理一帧、tile内存用光时的处理方式。amdgpu的HDMI 2.1 FRL初始支持也进了7.2，源头是Rodrigo Siqueira还在AMD时的工作，在主干之外躺了好几年。MGLRU这轮是清理加小改，动的是回收循环和脏页回写。sched_ext那边7.2铺了子调度器的地基，往后不同cgroup可以跑不同的自定义调度器；Igalia在这块干的是可观测性的活儿——自定义调度器出错被内核踢掉时，内核会把各CPU状态倒出来，核多了这份转储会被缓冲区截断，他们把出错那颗CPU排到最前面先倒。另外还有个ueagle-atm老驱动的竞态，syzbot这些年为它生成过好几份报告，这轮一并修了。

DRM调度器的公平策略是这轮唯一一件"做完了却没打开"的事。Igalia本来计划在7.2里把它设成默认，7.2-rc7那周收到一份回归报告，默认值又退回老的FIFO，公平策略留成可选项。他们说修法已经清楚，早期测试看着乐观，指望下个版本重新打开。

LWN那篇《7.2内核开发统计》此刻还在订阅墙后面，页面上写着，非订阅者可以在2026年8月27日免费读到它。