Zum Inhalt springen

Linux-Syscalls set_robust_list2 kehren in v7 für FEX-Emu zurück

Igalia hat am 25. September 2026 v7 der Futex-Syscalls set_robust_list2 eingereicht, 10 Monate nach v6. Sie sollen FEX-Emu helfen, 32-Bit-x86-Code auf Arm64 auszuführen.

Von Tech AI Wire Team

4 Min. Lesezeit

XLinkedIn
An Arm64 single-board computer wired to a monitor and a game controller on a desk, the monitor showing an out-of-focus 3D game scene.

André Almeida vom Beratungsunternehmen Igalia hat am 25. September 2026 Version 7 von zwei neuen Linux-Systemaufrufen eingereicht: set_robust_list2() und get_robust_list2(). Sie schließen eine Lücke, die Emulatoren wie FEX-Emu daran hindert, Sperren korrekt zu behandeln, wenn sie 32-Bit-x86-Programme auf Arm64-Rechnern ausführen. Es ist die erste neue Fassung seit v6 vom 22. November 2025.

Ein Systemaufruf, kurz Syscall, ist die feste Tür, über die ein Programm den Kernel um etwas bittet. Dieses Paar liegt jetzt in seiner siebten Version vor.

Was eine Robust-Futex-Liste leistet

Ein Futex ist eine Sperre, die im eigenen Speicher eines Programms liegt. Die Kernel-Dokumentation beschreibt Futexe als Sperren, die sich, wenn niemand sonst sie will, „aus dem Userspace erwerben und freigeben lassen, ohne den Kernel zu betreten“. Das macht sie schnell, und sie liegen unter gewöhnlichen Thread-Sperren wie pthread-Mutexen.

Das Problem beginnt, wenn ein Thread endet, während er noch eine Sperre hält. Andere Threads könnten dann ewig warten. Eine Robust-Futex-Liste löst das. Jeder Thread führt eine Liste der Sperren, die er hält, und teilt dem Kernel mit, wo diese Liste liegt. Meist verwaltet eine Bibliothek wie glibc die Liste.

Wenn der Thread endet, „durchläuft der Kernel die Liste sorgfältig“, so die Dokumentation. Er markiert jede Sperre des Threads mit dem Flag FUTEX_OWNER_DIED und weckt einen wartenden Thread. Der nächste Thread, der die Sperre nimmt, erfährt so, dass der vorige Besitzer mitten in der Arbeit beendet wurde.

Warum die alten Syscalls auf Arm64 scheitern

Heute meldet ein Thread seine Liste mit set_robust_list() an. LWNs Bericht über eine frühere Fassung dieser Arbeit erklärte zwei Grenzen. Der Aufruf erlaubt nur eine Liste pro Thread. Außerdem setzt er voraus, dass die Liste die native Zeigergröße der Maschine nutzt. Auf einem modernen Arm64- oder x86-64-System sind das 64 Bit.

Auf x86-64 hat der Kernel einen zweiten Kompatibilitätseinstieg, der die 32-Bit-Listen älterer x86-Programme versteht. Wie LWN schrieb: „Für AArch64 gibt es keinen solchen Compat-Einstieg.“ AArch64 ist der formale Name für 64-Bit-Arm. Ein 32-Bit-x86-Programm, das unter einem Emulator auf Arm64 läuft, kann seine Listen daher nirgends in seinem eigenen Format anmelden.

FEX-Emu ist ein solcher Emulator. Er übersetzt x86- und x86-64-Linux-Programme, damit sie auf Arm64-Hardware laufen, und ist der Anwendungsfall, den die v7-Patches nennen. Tech AI Wire hat vergangene Woche über die Darstellung des Projekts berichtet, warum x86-Emulation auf Arm so teuer ist.

Was sich in v7 ändert

Mit den neuen Syscalls kann ein Thread mehrere Robust-Listen halten, und jede Liste gibt an, ob sie 32-Bit- oder 64-Bit-Zeiger nutzt. Die wichtigste Änderung in v7 ist laut Anschreiben, dass die Schnittstelle „jetzt CREATE/MODIFY-Semantik statt SET nutzt“. Almeida schreibt, dass so „sowohl libc als auch App“ Robust-Listen „ohne Konflikte“ nutzen können.

Operation in v7Was sie tut
Create (32 oder 64)Legt eine neue Robust-Liste an und gibt ihren Index zurück
Modify (32 oder 64)Ersetzt den Kopf einer bestehenden Liste
Modify mit Null-KopfGibt den Platz dieser Liste frei
List limitMeldet, wie viele Listen ein Thread halten darf

Die Serie umfasst 10 Patches. Sie ist auf den aktuellen Mainline-Kernel angepasst. Almeida schreibt, dass er die Selbsttests für Robust-Listen erweitert und den alten Syscall auf die neuen Interna umgestellt hat. „Auf x86 und arm64 getestet“, heißt es im Anschreiben.

Die Arbeit wartete auf eine andere Korrektur. Laut Anschreiben geht es jetzt weiter, da „wir die op_pending-Race-Condition weitgehend behoben haben“. Das ist ein Fehler darin, wie eine laufende Freigabe festgehalten wird. Die Kernel-Dokumentation nennt den alten Freigabeweg „racy“. Eine Ziel-Kernelversion nennt das Anschreiben nicht.

Was das für Entwickler bedeutet

Die meisten Anwendungen werden diese Syscalls nie direkt aufrufen. C-Bibliotheken und Emulatoren schon. Wer eine libc, eine Thread-Laufzeit oder eine Übersetzungsschicht pflegt, sollte das v7-Anschreiben jetzt lesen. Das Create-und-Modify-Design soll ermöglichen, dass libc und Anwendung je eine Liste besitzen, ohne sich gegenseitig zu überschreiben. Genau auf diese Abstimmung wäre Ihr Code angewiesen.

Wer Software ausliefert, die unter FEX-Emu oder einem ähnlichen Arm64-Übersetzer läuft, sollte beobachten, ob diese Serie in einem veröffentlichten Kernel landet. Bis dahin kann 32-Bit-x86-Code auf Arm64 Robust-Listen weiterhin nicht in seinem eigenen Format anmelden.

Behandeln Sie die Details als vorläufig. Es handelt sich um einen Vorschlag auf einer Mailingliste, nicht um übernommenen Code, und die Schnittstelle hat zwischen v6 und v7 bereits ihre Form geändert. Bauen Sie nicht darauf, bevor ein Kernel-Release sie enthält.

Quellen

  1. [PATCH v7 00/10] futex: Create {set,get}_robust_list2() syscalls - Linux kernel mailing list
  2. futex: Create set_robust_list2 - LWN.net
  3. Robust futexes - The Linux Kernel documentation

Ähnliche Artikel