
2026/09/24 17:36
Loongson CPU に付与された失われた原子アップデートについて
RSS: https://news.ycombinator.com/rss
要約▶
Japanese 翻訳:
重要なハードウェアバグとして、LoongArch プロセッサに影響する CPU エラー (Erratum) が特定されました。これは、LA664 コアを採用する Loongson 3C6000/S および 3A6000 チップに限定されています。2026 年 2 月に Wang Miao 氏による Debian ソフトウェアのパッケージ化作業中に発見されたこの問題は、相互干渉するベクトルメモリ読み出しに関わる特定の条件下で原子命令(例えば
amadd)が偶発的に失敗することによって発生します。手動によるデバッグ活動が行われて半年間 Reproducer を削減できず、その後 2026 年 8 月に AI 支援分析によって memcpy が LSX/LASX ベクトル命令を使用して行われる場合、異なる物理コア上のスレッドが適切な同期またはデータバリアなしに動作する際に失敗が発生することが特定されました。
この欠陥は、リファレンスカウンター機構(例:Rust の
std::sync::Arc)を妨害し、使い捨て後の自由(use-after-free)脆弱性、ヒープ破損、ならびに OpenMP などの並列タスク中のプログラムクラッシュを引き起こすことで、ソフトウェアの信頼性に深刻な影響を及ぼします。テストでは、これらの特定の条件下でデータバリアが存在しない限り、原子操作が更新を失うことが約 100% の確率で確認されました。この問題は、データバリアの挿入または glibc のマルチアーキテクチャサポートを無効化することで成功裏に緩和されています(ただし後者は LASX の使用を完全に妨げます)。
コード変更を行わずにこれを恒久的に解決するため、Loongson は 2026 年 9 月 9 日にテスト用ファームウェアをリリースし、内部 MCSR24 CSR のビット 13 を設定してこのエラーを無効化しました。パフォーマンスへの影響は最小限であり、フルリリースは 10 月上旬頃を予定していました。即座に更新ができないユーザー向けの代替策として、Linux カーネル内でこの特定のビット設定を直接適用する手動ワークアラウンドが存在します。この発見は、Wang Miao 氏、Rong「Mantle」Bao 氏、ならびに Loongson のチップ R&D 部と開発者コミュニティ運用部の協力によってなされました。ARM を含む複数のベンダで同様のメモリアクセスまたは原子命令のエラーが発生していますが、ユーザー体験に重大な影響を与えるものは稀であり、これは並列処理環境における LoongArch の弱いメモリモデルに関連した注目すべき事件です。
本文
LoongArch CPU エラータ報告:失われた原子操作とファームウェア修正
TL;DR
- 問題発生: 2026 年 2 月、
パッケージのビルド時に無限ループが発生しました。normaliz - 原因特定: OpenMP の
で共有変数を更新する際、実際には増分されず(失われた更新)、終了条件を満たせなかったためです。#pragma omp atomic - 根本原因: **LoongArch 上の LASX ベクトル化メモリアドレス読取命令 (
)**と特定アドレスの原子操作が混在することで、CPU が原子性を欠くバグを引き起こしました。xvld - 解決策: Loongson 社は約 2 ヶ月で修正ファームウェア(MCSR24 レジスタ 13 ビットのセット)を開発し、国庆節前に提供予定です。
発端:コミュニティプロジェクトにおける無限ループ
- 背景:
プロジェクト(Debian 13 stable for LoongArch)のメンテナーが、loong13
パッケージをビルド中に遭遇した問題です。normaliz - 現象: ソースコードの組み込みテストで無限ループに陥り、パッケージ化がタイムアウトしました。
- 初期仮説: 以前他パッケージで経験済みの「競合条件」や「メモリ順序付け」によるものかと推測しましたが、LoongArch の弱いメモリモデル特有の問題ではないかと疑いました。
第一次調査:ソフトウェアと OpenMP の罠
- コードの構造:
は OpenMP を使用し、データポイント(リスト)を並列処理しています。normaliz- ループ終了条件は「処理済み数 (
) が総数 (nr_points_matched
) と一致する」ことに設定されています。nr_to_match
- 不具合のメカニズム:
- 処理済みカウンタが増加せず、すべての要素が「処理済み」マーク(
)されているにもかかわらずループ終了に至りませんでした。continue - 理論上
とnr_points_matched
は一致すべきでしたが、実際には値の不一致と不安定な差分が見られました。nr_points_done_in_this_round
- 処理済みカウンタが増加せず、すべての要素が「処理済み」マーク(
- 仮説検証:
- メモリ順序付けの問題ではないことが判明(他の変数との同期がないため)。
- OpenMP 実装の不備か?アセンブリを確認すると
命令が生成されていました。amadd.d - 最小限の再現例を作成しようとしたが、コードが複雑すぎたため根本的な解決策は見つからず、問題保留となりました。
第二次調査:AI を活用した根掘り葉掘り
- アプローチ: ソフトウェアバグではなくCPU ハードウェアの不具合である可能性を AI に分析させる手法に変更しました。
- 「他のアーキテクチャにはない」という事実や、問題が原子操作にあることを提示し、最小再現例の生成を指示しました。
- 発見:
- AI は処理関数内の
呼び出しに注目しました。memcpy - 根本原因: glibc の
がハードウェア能力(LSX/LASX)に基づきベクトル命令で加速される際、特定条件下で「失われた原子加算」を引き起こすことが判明しました。memcpy
- AI は処理関数内の
調査範囲の拡大:原子命令とメモリ操作
- 他の原子命令への影響:
- CAS (Compare-And-Swap) も同じ問題を抱えていることが確認されました。
,amswap
,ammax
なども同様の「失われた更新」が発生しますが、結果が正しくても検知が困難です。ammin
- トリガー条件の特定:
- LASX ベクトル化メモリアドレス読取 (
) が唯一の引き金でした。xvld - スカラー読取 (
など) は通常問題を引き起こしません(例外:原子アドレスと読み取りアドレスが特定位置関係にある場合)。vld
- LASX ベクトル化メモリアドレス読取 (
具体的な結論:失われた原子操作の条件
LoongArch 3A6000/5000 に比べ、3C6000/S と 3A6000 は LA664 コア(LA464)を採用し、SIMD 拡張を持っています。この環境で以下の 3 つの条件が同時に満たされるときに発生します:
- 物理コアの違い: 処理スレッドが異なる物理コア上で動作していること。(SMT ロジカルコア間では発生しない)。
- データバリアなし: 同一アドレスに対して、データバリア (
) を伴わない原子操作を実行していること。_db - メモリ読み取りの挿入: 少なくともいずれかのスレッドが原子操作の間や後に、メモリアドレス読取(LASX
)を挟んでいること。xvld
注意: LASX の場合、特定の位置関係にある場合は通常のスカラー読取でも発生する可能性があります。
再現と測定データ
最小限のテストプログラムによる統計結果(30 回試行中):
| 原子操作 | 両者 LASX コピー | 両者 LASX 読取 () | 片方 LASX コピー |
|---|---|---|---|
| 67% | 100% | 53% |
| 73% | 100% | 67% |
| 77% | 97% | 17% |
| 43% | 100% | 50% |
| 53% | 100% | 53% |
- 注: 「両者 LASX 読取」の条件でほぼ常に(100%)問題が発生します。
環境による再現性の違い(AOSC vs Debian)
- 2 月の状態: AOSC OS と Debian の両方で再現可能でした(両者とも
で LASX を使用)。memcpy - 8 月の状態: AOSC でのみ問題が消失し、Debian では依然として発生しました。
- 原因:AOSC Core 13 リリースで誤って glibc の
が無効化され、LASX 加速パスが使われなくなったためです。--enable-multi-arch - Debian は通常通り LASX を使用するため再現されました。
- 原因:AOSC Core 13 リリースで誤って glibc の
- 今後の見通し: AOSC が Core 14 でオプションを有効化すると問題が再び発生する可能性があります。
影響分析とセキュリティリスク
- 主な被害:
- メモリ安全性: リファレンスカウント(
)の増分が失われるため、実際の参照回数よりカウント値が小さくなり、早期解放 (use-after-free) を引き起こします。amadd - Rust の
やstd::sync::Arc
クローンでも同様のクラッシュや SIGABRT が発生しました。mpsc::Sender
- メモリ安全性: リファレンスカウント(
- セキュリティリスク:
- 低い: 同じオブジェクトの同一カウンタに対して、2 スレッドが同時に弛緩した原子操作とベクトル読み取りを行う必要があり、プロセス内でのみ成立するためです。
- プロセス隔離により悪用は困難です。
回避策
- ソフトウェアレベル: 開発者がコンパイラ生成の原子操作を制御できません。コンパイラ側でデータバリア付き命令 (
) または LL/SC ループへ移行する必要がありますが、既存バイナリへの適用には再コンパイルが必要です。_db
修正内容:ファームウェア更新
Loongson 社への報告後、迅速な対応が実現しました。
- 提出: 2026 年 8 月 26 日
- 受領: 2 ヶ月後の 9 月 9 日(テスト用ファームウェア)
- 公開予定: 国庆節(10 月 1 日)前
修正の詳細
- 技術内容: MCSR24 レジスタの 13 番ビットを
に設定します。1- この内部 CSR を設定することで「失われた更新」が防止されます。
- パフォーマンスへの影響は最小限(シングルコア無影響、マルチコアわずかな低下)。
- 手動修正: ファームウェアアップデートが難しいユーザーは、Linux カーネル内で直接このビットを書き込むことで回避可能です。
結論
- この問題は、パッケージビルド時の無限ループというソフトウェアの誤作動から始まり、CPU の原子操作命令が原子性を欠くハードウェアバグであることが発覚しました。
- AI と人間の連携により、半年間かけて原因を特定・修正にたどり着きました。
- ARM や他のメーカーでも類似のエラータは存在しますが、早期に特定しファームウェアで修正することが重要です。
謝辞
- 調査の主導:王苗さん
- 再現テストと報告書執筆:著者
- 追加発見(
の問題など):栄「曼陀羅(Mantle)」包氏amcas - 修正対応:龍芯 社 チップ R&D 部・開発者コミュニティ運営部 へ感謝申し上げます。