技术动态：MongoDB、TCMalloc 与 Linux 内核的 RSEQ 之争

1. 事件背景

2026年初，随着 Linux 内核 6.19 版本的发布，大量 MongoDB 用户发现数据库在启动时崩溃（报错代码 exit 139）。经排查，问题的根源在于内核、内存分配库 TCMalloc 以及内核特性 RSEQ 之间的兼容性崩溃。

2. 技术冲突

• RSEQ（重启序列）： 一项旨在让用户态程序无需锁或原子指令即可快速访问 CPU 数据的内核特性。
• TCMalloc 的“巧妙黑客手段”： 为了追求极致性能，Google 的 TCMalloc 库利用了 RSEQ 中一个未记录在规范文档里的内核行为——通过监测 cpu_id_start 字段的自动更新来感知 CPU 调度切换。
• 内核代码重写： 内核开发人员在 6.19 版本中为了优化 RSEQ 性能，重写了相关逻辑。由于该行为本就属于“未定义的潜规则”，新内核停止了对该字段的无条件更新，直接导致 TCMalloc 逻辑失效，引发 MongoDB 崩溃。

3. 各方博弈

• 内核开发者： 认为 TCMalloc 多年来一直违规使用非正式接口，且早已收到警告却拒绝修复，因此拒绝回滚内核代码。
• MongoDB/用户方： 认为“内核不应破坏用户态程序”是基本准则，且 TCMalloc 的做法虽是“黑客行为”，但确实大幅提升了性能。
• Linus Torvalds 的裁定： Linux 之父最终介入并斥责了内核开发团队。他强调：“我们不破坏用户空间”是第一准则。他认为所谓的“规范”并不如“实际运行结果”重要，如果一个巧妙的技巧能工作多年，那么它就是事实上的标准。

4. 现状与建议

目前内核社区正在着手修复此回归问题。在补丁发布前，受影响的用户可以：
* 临时方案： 设置环境变量 GLIBC_TUNABLES="glibc.pthread.rseq=1"。这会强制启用标准库的 RSEQ 从而禁用 TCMalloc 的相关逻辑。
* 代价： 该方案虽能避免崩溃，但会导致 MongoDB 失去针对 CPU 缓存优化的性能优势。
* 长期方案： 等待内核发布修复补丁，或暂时停留在 6.19 之前的内核版本。