Linuxのset_robust_list2システムコール、FEX-Emu向けにv7が登場

コンサルティング会社IgaliaのAndré Almeida氏は2026年9月25日、Linuxの新しいシステムコール2つ、set_robust_list2()とget_robust_list2()のバージョン7を投稿した。これらは、FEX-Emuのようなエミュレーターが32ビットのx86プログラムをArm64マシンで動かすときに、ロックを正しく扱えない問題を解消する。新しい版が出るのは、2025年11月22日のv6以来初めてだ。

システムコールとは、プログラムがカーネルに何かを頼むときに使う決まった入り口のことだ。この2つは今回で7版目になる。

robust futexリストの役割

futex（フューテックス）は、プログラム自身のメモリ上に置かれるロックだ。カーネルのドキュメントは、futexを、他に使いたい者がいなければ「カーネルに入ることなくユーザー空間から取得・解放できる」ロックだと説明している。そのため高速で、pthreadミューテックスのような普通のスレッド用ロックの土台になっている。

問題は、スレッドがロックを持ったまま終了したときに起きる。ほかのスレッドは永遠に待ち続けるおそれがある。robust futexリストはこれを解決する。各スレッドは自分が持つロックの一覧を保持し、その一覧がどこにあるかをカーネルに伝える。一覧は通常、glibcのようなライブラリが管理する。

ドキュメントによると、スレッドが終了すると、カーネルは「一覧を注意深くたどる」。そのスレッドが持っていたロックすべてにFUTEX_OWNER_DIEDというフラグを付け、待っているスレッドを1つ起こす。次にロックを取ったスレッドは、前の持ち主が作業の途中で終了したことを知る。

従来のシステムコールがArm64で通用しない理由

現在、スレッドは一覧をset_robust_list()で登録する。この取り組みの以前の版を報じたLWNの記事は、2つの制約を説明していた。1つのスレッドにつき一覧は1つしか持てない。また、一覧がそのマシン本来のポインターの大きさを使う前提になっている。最近のArm64やx86-64のシステムでは、それは64ビットだ。

x86-64では、カーネルに2つ目の互換用の入り口があり、古いx86プログラムの32ビットの一覧を理解できる。LWNの言葉では「AArch64にはそのような互換用の入り口がない」。AArch64は64ビットArmの正式名称だ。そのため、Arm64上のエミュレーターで動く32ビットx86プログラムには、自分の形式で一覧を登録する場所がない。

FEX-Emuは、そうしたエミュレーターの1つだ。x86とx86-64のLinuxプログラムを変換してArm64のハードウェアで動かすもので、v7のパッチが名指しする用途でもある。Tech AI Wireは先週、Arm上のx86エミュレーションがなぜ高くつくのかについての同プロジェクト自身の解説を取り上げた。

v7で変わること

新しいシステムコールでは、1つのスレッドが複数のrobustリストを持てる。それぞれの一覧は、32ビットと64ビットのどちらのポインターを使うかを宣言する。カバーレターによると、v7の主な変更は、インターフェースが「SETではなくCREATE/MODIFYの方式を使う」ようになったことだ。これにより「libcとアプリの両方」が「衝突なく」robustリストを使えるとAlmeida氏は書いている。

v7の操作	内容
Create（32または64）	新しいrobustリストを用意し、その番号を返す
Modify（32または64）	既存の一覧の先頭を置き換える
先頭をnullにしたModify	その一覧の枠を解放する
List limit	1つのスレッドが持てる一覧の数を返す

このシリーズは10本のパッチからなる。現在のメインラインのカーネルに合わせて作り直されている。Almeida氏は、robustリストのセルフテストを拡張し、従来のシステムコールを新しい内部実装の上に移したと書いている。カバーレターには「x86とarm64の両方でテスト済み」とある。

この作業は、別の修正を待っていた。カバーレターは、「op_pendingの競合状態をほぼ修正した」ので作業を再開したと述べている。これは、進行中のロック解放をどう記録するかに関わる欠陥だ。カーネルのドキュメントも、従来の解放の仕組みを「競合がある」と呼んでいる。カバーレターは、取り込み先のカーネルのリリースを挙げていない。

開発者にとっての意味

ほとんどのアプリケーションのコードは、これらのシステムコールを直接呼ぶことはない。呼ぶのはCライブラリやエミュレーターだ。libcやスレッドのランタイム、変換レイヤーを保守しているなら、今のうちにv7のカバーレターを読んでおこう。作成と変更を分ける設計は、libcとアプリケーションがそれぞれ一覧を持っても互いを壊さないためのものだ。その調整こそ、あなたのコードが頼ることになる部分だ。

FEX-Emuや同様のArm64向け変換ツールの上で使われるソフトウェアを出しているなら、このシリーズがリリース版のカーネルに入るかどうかを見守ろう。それまでは、Arm64上の32ビットx86コードは、自分の形式でrobustリストを登録する手段を持たないままだ。

細部は暫定的なものとして扱ってほしい。これはメーリングリスト上の提案であり、取り込まれたコードではない。インターフェースはv6からv7の間ですでに形を変えている。カーネルのリリースに入るまでは、これを前提に開発しないことだ。