トーバルズ、Intel GPUドライバのバグをAIと追い詰める。24パッチ、18回の再起動

Linuxの生みの親リーナス・トーバルズ（Linus Torvalds）氏が、Intel Xeグラフィックスドライバのバグを自ら修正した。24個のパッチと18回のカーネル再起動を経て、AIの支援でたどり着いた修正はたった1行の変更だった。

round_up()をround_down()に

トーバルズ氏が現地時間8月20日にLinuxカーネルのGitリポジトリへコミットした修正は、Intel Xeカーネルドライバの1行だけを書き換えるものだった。

問題はXeドライバがVRAMの割り当て境界を計算する方法にあった。ドライバはCCS（Compute Command Streamer、GPU内のコンピュート専用エンジン）が使う圧縮メタデータ用に予約されたメモリ領域の先頭アドレスを取得し、128KBの境界に切り上げていた。このround_up()が間違いだった。

切り上げると、実際のCCS領域よりも先のメモリまで「使っていい」とドライバが判断してしまう。CCS領域の直後にある本来は使えないメモリが、通常のVRAMとして公開される。ハードウェアのGPUエンジンもその領域に書き込む。

この領域がGPUのページテーブル（VRAMのどこにどのデータがあるかを管理する索引）に割り当てられると、ページテーブルが破壊される。トーバルズ氏のBattlemage G21搭載マシン（Intel Arc B580等に使われるGPUチップ）では、Mesaの仮想マシン用レベル3ページテーブルがまさにこの「壊れる」ページに乗ってしまい、コンポジタ（画面合成を担うプログラム）の初回描画でメモリアクセスエラーが発生し、GNOME Display Manager（GDM、ログイン画面の管理プログラム）が無限に再起動し続ける症状を引き起こしていた。

修正はround_up()をround_down()に変えるだけ、1行の書き換えにすぎない。切り下げれば、CCS境界の手前で使用可能なVRAMの範囲が終わり、ハードウェアが勝手に書き込む領域と衝突しなくなる。

このバグの原点は2年前のコミット37173392741c（"drm/xe/vram: fix ccs offset calculation"）にあった。なぜ今になって再現性が高くなったのかは不明だが、ユーザースペース（OS上で動くアプリケーション層）の何らかの挙動変化がトリガーを引いたとトーバルズ氏はメーリングリストで推測している。ランダムに発生していた画面の乱れも、これで説明がつく可能性がある。

「地獄のデバッグ」とAIの記録

修正が1行で済んだ事実は、バグの追跡が容易だったことを意味しない。コミットメッセージに、トーバルズ氏はデバッグの過程を率直に記録した。

And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work.

（これは地獄のデバッグセッションだった。AIが力仕事の大半をこなし、大いに助けられた）

I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it.

（疲れ知らずの助手と呼びたいところだが、AIは何度も「これは不可能で解決できない、レポートを書くべきだ」とはっきり言い切った）

I suspect those things have been trained by people who may not be quite as stubborn as I am.

（自分ほど頑固ではない人たちによって訓練されたのだろう）

But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above.

（だがAIは何度も諦めかけながらも、私が押し返すたびにデバッグコードを追加し、忠実に分析を続けた。功績を認めるべき相手には、ちゃんと功績を認める。だからコミットメッセージの本体はAIに書かせた）

24個のデバッグパッチを重ね、18回カーネルを再起動して原因を絞り込む過程で、AIはコードの追加と分析という反復作業を担い続けた。トーバルズ氏が方向を示し、AIが手を動かし、結果を見てまた方向を修正する。AIが「無理だ」と言っても、トーバルズ氏は引き下がらなかった。

使用されたAIの具体名は明かされていないが、トーバルズ氏は今年1月にGoogle Antigravity（Windsurfフォーク）でAI支援のPythonコーディングを行っていたことが確認されている。

修正はLinux 7.3のGitリポジトリにマージされ、安定版カーネルへのバックポート（過去バージョンへの修正適用）も予定されている。Linux 7.2が8月16日にリリースされ、7.3のマージウィンドウが開いた直後のタイミングだった。

3か月で変わった景色

このコミットメッセージが異彩を放つのは、トーバルズ氏とAIの関係がこの1年で急速に変化してきた文脈がある。

2024年4月、トーバルズ氏はAIの誇大宣伝を「笑える」と切り捨てていた。2026年1月にはサイドプロジェクトでAIにコードを書かせる「バイブコーディング」を試み始めた。5月にはOpen Source Summit North Americaの基調講演で、AIツールによってカーネルのコミット数が約20%増加したと報告しつつも、AIによるバグレポートの洪水がセキュリティメーリングリストを「ほぼ完全に管理不能」にしていると警告した。

7月には、AIによるカーネルパッチレビューシステム「Sashiko」をめぐる議論で、明確に立場を示した。「Linuxは反AIプロジェクトではない。それが気に入らないなら、オープンソースの流儀でフォークすればいい。あるいは去ればいい」。人が責任を持つ限り、AIツールの利用は認めるという原則を打ち出した。

そして8月、トーバルズ氏自身がAIをデバッグの実戦に投入し、成果を公に認めた。

ここまでの軌跡を見ると、トーバルズ氏のAI観は「笑い話」から「使えるもの」へ一方向に進んだように見える。だが今回のコミットメッセージは、もっと入り組んだ現実を映している。AIは何度も投げ出そうとした。トーバルズ氏はそのたびに押し返した。結果的にAIは役に立ったが、AIの「判断」（もう無理だからレポートにしよう）をそのまま受け入れていたら、バグは直らなかった。

「自分ほど頑固でない人たちによって訓練された」。この一文は、AIの限界が技術的な能力ではなく、訓練データに反映された人の振る舞いにあると指摘している。難しい問題に直面したとき、多くの人が「これ以上は無理だ」と判断を下す。AIはその判断パターンを学んでいる。

Linux 7.2リリース前後、トーバルズ氏はAIツールによるレビューが「巨大なリリース候補」の一因になっていると述べ、「新しい日常」という表現を使った。バグを見つけるAI、バグレポートを大量に送りつけるAI、コードレビューをするAI。そして今回、バグを追い詰める力仕事を淡々とこなすAI。

Linuxカーネルの開発現場でAIが果たす役割は、「使うか使わないか」の段階をとうに超えている。AIが「これは無理です」と言ったとき、押し返すかどうかは人が決める。24パッチと18回の再起動の先に、1行の修正があった。

関連記事

• Linux 7.2リリース。キャッシュを理解するCPUスケジューラが到着
• Linux 7.2最終RC、AI関連の修正提案が継続　採用状況を整理
• LinuxカーネルのstagingがLLMパッチを自動拒否へ。例外はセキュリティ修正のみ
• Linux 7.2-rc5公開。パッチ量は膨張、中身は平穏
• Linux 7.1-rc3公開、カーネル肥大は「新常態」だ
• LLMによるコード調査を受けLinuxカーネルが27年前のドライバーを削除
• 反AIオープンソース、共通の敵と内部の亀裂
• Debian、LLM利用の全面禁止か条件付き容認かを正式投票へ
• LinuxカーネルCVE、2日で432件公開の衝撃
• GNOME、セキュリティ開示を90日から30日に短縮