Linus 亲自下场让大模型看 Intel 显卡驱动的崩溃转储

一、事情没网上传得那么神

上周内核邮件列表（LKML）那帖子刷屏时，标题全是「Linus 拥抱 AI」「Linux 之父让大模型修 Bug」。我点开那封回复链接看原文，上下文根本不是什么「AI 自动修复驱动」，而是有人把 dmesg 里的 oops 信息、栈回溯、寄存器状态扔给模型，让它帮忙定位哪条指令触发的 page fault。

模型输出的建议是：xe_gt_tlb_invalidate 路径下某个未初始化的指针解引用。Linus 回复很干脆：「看起来像那么回事，我先应用上，回头跑压力测试。」——全程没让模型写一行补丁代码，也没让它跑 git bisect。别被标题党带偏了，这顶多算「辅助分析崩溃转储」，离「调试驱动」还差十万八千里。

二、为什么偏偏是这块 Intel Xe 代码？

Intel 新一代 xe 驱动（取代老 i915）上主线才多久，锁层级、GT/引擎拓扑、TLB 失效流程全是新写的 C 代码，边界条件极多。上周那个崩溃典型特征：RIP 指向 xe_gt_tlb_invalidate+0x47，CR2 是个明显未对齐的地址，栈里却没有明显的 NULL 指针检查失败。

这种「寄存器值看得出异常，但控制流跳转路径极深」的场景，最烧人脑子。维护者得把几百行带锁的异步提交路径在脑子里跑一遍，还要对照硬件规格书确认 TLB 失效时序。扔给模型的优势显而易见：它见过海量类似的 oops 模式，能秒级把「指针解引用偏移 0x47」映射到结构体第几个字段、哪个调用者忘加 NULL 判断。

但别忘了，模型根本不懂 struct xe_gt 的生命周期，也不清楚 mutex_lock(&gt->tlb_lock) 保护的是哪段临界区。它给的只是统计概率上的「嫌疑点」，真正决定「这个补丁能不能进主线、会不会引入回归」的，还是 Linus 那套基于经验的直觉和后续的 igt-gpu-tools 全套跑分。

三、大模型在内核维护里真能坐主力吗？

我把同样的 oops 扔给三个不同模型跑了跑：

• 两个给出了同一个嫌疑函数，但修复建议一个是加 if (!ptr) return -EINVAL;，另一个直接建议 ptr = get_valid_ptr();——后者明显胡编乱造，内核里根本没有这个 helper。
• 第三个模型直接幻觉出一个「这是已知的硬件擒纠 0x1234，需升级微码」的结论，查 Intel 规格书根本没有这个擒纠。

结论很清楚：模型对「模式识别」极强，对「不变量维护」一窍不通。内核驱动调试的核心从来不是「找到哪行崩了」，而是「证明修完这行、在所有并发/热插拔/电源管理路径下依然正确」。这部分模型完全插不上手，Linus 自己也没指望它插得上手。

四、别把「辅助分析」吹成「AI 维护内核」

这次事件最大的信息量其实在 Linus 的态度：他不排斥用新工具提效，但绝不放权。就像当年 git 取代 BitKeeper、clang 静态分析进入 CI，都是工具链升级，核心决策权永远在人手里。

下次再看到标题「AI 修复 Linux 驱动 Bug」，先问一句：它跑 make -j$(nproc) && kselftest 了吗？它对着 Documentation/process/submitting-patches.rst 检查提交格式了吗？没干这些，全是看热闹不嫌事大的营销号文案。