LoongArch 处理器系列被发现一个不显性的一阶硬错误:在 LA664 核心(主要用于 3C6000/S 和 3A6000)的特定条件下,无数据屏障的原子加、原子比较交换等指令会出现更新丢失。而这起排查中真正值得注意的是:从 2026 年 2 月首次观察到现象,到 8 月借助 AI 在两天内复现并锁定根因,前后耗时近半年,但真正起决定作用的两天里 AI 和开发者都不可或缺。
从一个打包死循环说起
故事开始于 2026 年 2 月,LoongArch64 移植版 Debian 13(代号 loong13)维护者王邈在为 normaliz 数学软件打包时,撞上一次死循环:程序卡在循环里退不出来,原因是累计计数永远追不上目标值。OpenMP 编译指示 #pragma omp atomic 看上去是按规范写的,反汇编也确认编译器生成了 LoongArch64 的 amadd.d 原子加指令,符合预期。
排查一度陷入死胡同:把 normaliz 的逻辑简化成最小测试程序时,无法复现;在 normaliz 实际代码里逐段注释、缩小范围,问题依然顽固。6 个月里,先后怀疑过内存序、OpenMP 实现、龙芯的指令语义,都没有结果。
AI 两天内锁定 LASX 向量化内存读取
8 月,开发者换了个做法:不再由人去定位,而是让 AI 去寻找最小复现,人负责指挥 AI 的调查方向。第一轮 AI 注意到循环异常,但没有得出原子加存在问题的结论;提示该问题只在 LoongArch 上出现,AI 也未能给出明确判断;直到开发者直接告诉 AI 已经定位到原子加有问题,要求它给出最小复现样例,AI 才把注意力放到 glibc memcpy 的向量化实现上。
两天后,AI 给出了一个能稳定复现的最小程序:每条线程对每个数据点先做一次向量化内存搬运,再对共享计数器做一次 relaxed 原子加。复现需要同时满足三个条件:线程运行在不同物理核上、对同一地址执行不带数据屏障的原子操作、其中至少一个线程穿插了内存读取。
进一步追查,熔化过程在 LASX 256 位 SIMD 读取指令 xvld 上最易触发,概率几乎到 100%;LSX 128 位读取 vld 不触发;独立研究者 Rong "Mantle" Bao 还发现,当原子变量所在的内存地址与读取地址满足特定位置关系时,普通标量读取也能触发,只是概率更小。glibc 中 memcpy 会按硬件特性自动选择最优实现,在启用 --enable-multi-arch 的系统里走 LASX 路径,这就解释了为什么在 Debian 上稳定复现、AOSC OS 却复现不出来:后者在 2 月后发布的 Core 13 版本里误关了 --enable-multi-arch,无意间规避了这个 bug。
多个原子指令都受影响,影响超出 normaliz
进一步验证发现,受影响的不只是 amadd,还包括 amcas、amswap、ammax、ammin、amxor、amand、amor 等多个原子操作。带 data barrier 的版本(am<OP>_db.*)则不受影响,这也是为什么带屏障的 amcas_db.d 在同样条件下失败率为 0%。
ammax、ammin 等没有 C 标准对应接口,编译器通常不会生成;amcas 属于 LoongArch64 v1.1 新指令,默认也不会生成。但 amadd 在引用计数场景非常常见——Rust 标准库中 std::sync::Arc 的引用计数、std::sync::mpsc 的 Sender 克隆,都用了不带数据屏障的 amadd。作者用 safe Rust 程序构造了两个测试,触发后表现为 SIGABRT 或 glibc 报告堆被破坏,意味着已经造成 use-after-free。
不过该问题难以被用于安全攻击:两个线程必须对同一进程内同一对象的同一计数器并发操作,无法跨越进程隔离,因此不太可能被远程利用。AI 在整个排查中的角色,更像是"快速生成假设 + 自动最小化复现",而不是独立完成推理——开发者事先已经做了第一轮排查,知道现象是什么、要找什么,才能引导 AI 把注意力放到 memcpy 上。
龙芯两周修复,固件 10 月 1 日前发布
8 月 26 日开发者把问题反馈给龙芯,9 月 9 日就拿到了测试固件,3A6000 和 3C6000/S 实测都恢复正常,修复速度超出常态。龙芯给出的修复方式是设置内部 CSR MCSR24 的 bit 13,该寄存器手册中并未注明功能;设置后问题不再复现,且单核性能无影响,多核性能略微下降。
如果用户暂时无法更新主板固件,也可以在 Linux 内核里直接写入该 bit,等效完成修复。详细复现条件、benchmark 表与规避方法见原作者 jia.je 的博客(https://jia.je/hardware/2026/09/24/loongson-cpu-erratum/)。龙芯已表示该固件将在国庆节前公开发布。
这起事件真正的教训不是"AI 能找 bug",而是"AI 在人给出方向后能把模糊假设压成最小复现"。6 个月的卡顿被压缩到 2 天,前提是开发者已经知道 bug 在哪里、问对了问题;AI 只是把人不愿意做的注释化、编译、运行、缩小的体力活接了过去。CPU 漏洞并不稀奇,ARM 公版核的 errata 文档里同样有访存、原子指令相关的条目;难的是在用户报上来的真实故障里,把这颗头真正钉出来。