アロケーターがCCSストレージを利用可能なVRAMとして扱うと、通常のメモリー割り当てが予約領域と重なり、GPUのメタデータを上書きする可能性がある。
つまり、単純な算術ミスというより、「この値は何を意味しているのか」という認識のずれが本質だった。コードは値を開始アドレスのようにアラインメントしていたが、実際には使用可能なメモリーがどこで終わるかを示す上限だったのである。
最終的な修正が小さかったにもかかわらず、原因の特定が難しかったのはこの意味上の食い違いにあった。
Torvalds氏は今回の作業を「地獄のデバッグセッション」と表現した。氏とAIアシスタントは、対象を絞った計測処理を追加・修正しながら、ドライバー内のメモリー計算を追跡した。そして、ハードウェアが報告するCCSの位置と、VRAMアロケーターに渡される境界を比較した。
何度もカーネルを起動したことには意味がある。今回の異常は、ソースコード上で怪しい1行を見つければ終わる問題ではなく、ハードウェアやディスプレイシステムの動作として現れていたからだ。各実験によって、グラフィックス障害の原因がメモリー割り当てなのか、それとも別の要因なのかを切り分けていった。
Torvalds氏はAIを、対話型のデバッグ相手として利用した。AIは計測処理の案を出し、ドライバー内のコードパスをたどり、実験結果の分析を補助した。仮説を試す際の機械的で反復的な作業を減らした点は大きい。
しかし、AIの判断をそのまま信頼できたわけではない。Torvalds氏によると、AIは何度も「この問題は不可能、あるいは解決不能だ」と結論づけ、調査を打ち切って報告書を書くことを提案したという。そこで氏は、次に何を試すかを決め、誤った解釈を退け、オフセットがアロケーターのメモリーモデル上で何を意味するのかを判断し続けた。
ここが今回の事例の核心だ。AIは可能性を列挙し、作業を進めるための材料を提供した。一方で、専門知識をもとに仮説を立て、検証可能な実験を設計し、結果を評価し、最終的な修正を決めたのは人間だった。
Intel Xeドライバーの修正は、Torvalds氏自身が作成して上流のLinuxカーネルにコミットした。影響を受ける保守対象の安定版カーネル系列には、通常のバックポート手順を通じて修正が取り込まれる見込みだが、提供された情報だけでは、対象となる具体的な安定版のバージョンやリリース日を確実に特定できない。
そのため、現時点で特定のバックポート版を断定するのは早計だ。該当するハードウェアを利用している場合は、ディストリビューションやカーネルメンテナーからの告知を確認し、修正が含まれるビルドかどうかを判断する必要がある。
今回の出来事は、AIが生成したカーネルコードを無条件に認める話ではない。より限定的で、実務に即した結論は、専門家が主導するデバッグのループをAIで高速化できる、というものだ。
専門家は仮説を立て、検証方法を設計し、変更内容を確認し、結果に責任を持つ。これは、検証していないAI生成パッチや、依頼されてもいない脆弱性報告を大量にメンテナーへ送ることとは大きく異なる。
Linuxカーネル開発者からは、機械生成の投稿が「大挙して押し寄せている」との指摘が出ている。stagingサブシステムやネットワーク関連のメンテナーからも、価値が低い、または内容を理解しないまま提出されたパッチへの強い不満が報告されている。
「投稿数が2,700%増えた」という頻繁に引用される数字については注意が必要だ。今回提供された情報からは、その測定方法、対象期間、あるいは全投稿・特定サブシステム・特定のパッチ分類のどれを指すのかを確認できない。一方で、AIによってコードや報告書を作るコストが下がった一方、レビューや振り分けにかかる負担は人間のメンテナーに残っている、という一般的な問題は十分に裏付けられている。
今回のIntel Xeのデバッグセッションが示したのは、AIが規律ある開発プロセスの中では有用な道具になり得る一方、サブシステムへの深い理解、再現可能なテスト、そして成果物に対する人間の責任を置き換えるものではないということだ。
最終的なパッチは1行だった。だが本当の成果は、その1行を変更すべきだと見抜き、AIが「答えは見つからない」と告げても調査を止めなかったことにある。