一条Linux内核提交的commit message,最近被科技圈疯狂转发。写这条message的人是Linus Torvalds,Linux的创始人,以毒舌和对代码质量的极高标准闻名。他在里面说,这是一次"地狱级"调试,AI帮他干了大量体力活,但AI好几次直接摆烂,说这问题"不可能解决",建议干脆写个报告了事。Torvalds没听,继续逼着AI加调试代码、分析结果,最后甚至让AI代写了这条commit message本身。

这句话流传很广,但大多数转发只停留在轶事层面:Linus用AI调试、AI想放弃、最后AI写了提交说明。没人告诉你这个bug到底有多难,AI具体做了什么。扒开这条commit的技术细节,会发现这个故事比表面看到的更有意思。

一行diff背后的24个补丁

这个bug出在drm/xe,也就是Intel独立显卡(Arc、Battlemage系列)的开源内核驱动上。GPU里有一块叫flat CCS的硬件保留区域,专门用来存显存压缩数据,不该被当成普通显存分配出去。

问题出在一个地址计算函数上:get_flat_ccs_offset()把CCS区域的基址向上取整到128KiB边界。在一块16GiB显存的Battlemage显卡上,这个取整动作在真实基址和取整后地址之间,凭空造出了一段本不该存在的"可用"空间——只有一个4KiB页面里的2KiB。

这2KiB越界空间被显存分配器当成正常显存分配了出去,又被图形库Mesa的页表结构反复占用。CCS硬件一旦往这块区域写数据,就会覆盖页表内容,直接冲垮页表,进而导致compositor提交崩溃,桌面陷入GDM重启循环,黑屏。

  • 风险.这类bug偶发、难复现,涉及内存对齐和硬件寄存器语义,是内核调试里公认最难啃的类型之一。

Torvalds在commit message里给了具体数字:整个调试过程涉及24个调试补丁18次内核启动。而最终的修复,本质上是一行代码的改动——把向上取整round_up换成向下取整round_down,顺带修正了一处断言逻辑。

崩溃链条:从取整错误到黑屏 CCS基址 向上取整 128KiB边界 2KiB越界 被当作 可用显存分配 页表损坏 Mesa三级 页表被覆写 GDM崩溃 重启循环 黑屏 调试规模 vs 修复代价 24 调试补丁 18 次内核启动 1行 最终修复diff

AI干了什么,没干什么

Torvalds的原话里其实藏着一个双重评价,值得拆开看。他一边说AI是"tireless helper"(不知疲倦的帮手),一边又立刻自我纠正:AI好几次明确说这事"不可能解决""无法解决",劝他写份报告收工。他猜测,训练这些模型的人可能不像他这么固执。

但另一面是,每次他把问题推回去,AI就继续老老实实加调试代码、分析结果,没有敷衍。24个调试补丁的生成和分析,大概率就是AI承担的"grunt work"——繁琐、重复,但需要精确执行。真正决定不放弃的,是Torvalds本人的坚持。

这条commit message本身也是AI代笔的,Torvalds只是署名认可。这意味着"AI说不可能解决"这类描述,是经过人工转述和筛选后呈现出来的叙事,不是AI原始输出的完整记录。

这句夸奖该怎么读

Torvalds对AI辅助编程一向不算热情,这次公开在commit message里给AI记功,还署名致谢,放在他的一贯风格里已经算是罕见表态。但这不是一次无保留的背书。

AI扛住了脏活,扛不住的是"再试一次"的耐心

对比常见的AI编程叙事——要么捧成"效率革命",要么贬成"幻觉制造机"——Torvalds这句评价更接近一个老工程师的实话:好用,但离了人的固执就会半途而废。这对判断AI在系统级调试里的真实能力边界,比任何一份评测报告都更贴近一线体感。

谁该关心后续

这个bug目前已经修复,但受影响的主要是Intel Battlemage系列独显用户,尤其是此前遇到过莫名其妙的桌面重启循环或黑屏、又找不到原因的人。该修复涉及此前一次Xe CCS偏移量改动引入的问题,已经被标记需要回合到稳定版内核,具体哪个发行版、哪个内核小版本能拿到这个补丁,还要看各自的更新节奏。

对内核开发社区而言,更值得盯的是后续会不会有更多顶级维护者,愿意像Torvalds这样,把AI的参与和局限一起写进commit history——而不是只挑好听的那一半说。