Les appels système Linux set_robust_list2 reviennent en v7 pour FEX-Emu

André Almeida, du cabinet de conseil Igalia, a publié le 25 septembre 2026 la version 7 de deux nouveaux appels système Linux, set_robust_list2() et get_robust_list2(). Ils comblent une lacune qui empêche des émulateurs comme FEX-Emu de gérer correctement les verrous lorsqu'ils exécutent des programmes x86 32 bits sur des machines Arm64. C'est la première nouvelle révision depuis la v6 du 22 novembre 2025.

Un appel système, ou syscall, est la porte fixe par laquelle un programme demande quelque chose au noyau. Cette paire en est maintenant à sa septième version.

À quoi sert une liste de futex robustes

Un futex est un verrou qui vit dans la mémoire du programme lui-même. La documentation du noyau décrit les futex comme des verrous qui, quand personne d'autre ne les demande, « peuvent être acquis et libérés depuis l'espace utilisateur sans entrer dans le noyau ». Cela les rend rapides, et ils servent de base aux verrous de threads ordinaires comme les mutex pthread.

Le problème survient quand un thread meurt alors qu'il détient encore un verrou. Les autres threads pourraient alors attendre indéfiniment. Une liste de futex robustes règle ce problème. Chaque thread tient une liste des verrous qu'il détient et indique au noyau où se trouve cette liste. C'est généralement une bibliothèque comme glibc qui la gère.

Quand le thread se termine, le noyau « parcourt la liste avec soin », selon la documentation. Il marque chaque verrou détenu par le thread avec le drapeau FUTEX_OWNER_DIED et réveille un thread en attente. Le thread suivant qui prend le verrou apprend ainsi que son précédent propriétaire est mort en pleine tâche.

Pourquoi les anciens appels système échouent sur Arm64

Aujourd'hui, un thread enregistre sa liste avec set_robust_list(). L'article de LWN sur une version antérieure de ce travail expliquait deux limites. L'appel n'autorise qu'une seule liste par thread. Il suppose aussi que la liste utilise la taille de pointeur native de la machine, soit 64 bits sur un système Arm64 ou x86-64 moderne.

Sur x86-64, le noyau dispose d'un second point d'entrée de compatibilité qui comprend les listes 32 bits des anciens programmes x86. Comme l'écrivait LWN, « il n'existe pas de tel point d'entrée de compatibilité pour AArch64 », le nom officiel de l'Arm 64 bits. Un programme x86 32 bits qui tourne dans un émulateur sur Arm64 n'a donc nulle part où enregistrer ses listes dans son propre format.

FEX-Emu est l'un de ces émulateurs. Il traduit les programmes Linux x86 et x86-64 pour qu'ils tournent sur du matériel Arm64, et c'est le cas d'usage que citent les correctifs v7. Tech AI Wire a présenté la semaine dernière l'explication du projet sur le coût de l'émulation x86 sur Arm.

Ce qui change dans la v7

Les nouveaux appels système permettent à un thread de détenir plusieurs listes robustes, et chaque liste indique si elle utilise des pointeurs 32 bits ou 64 bits. Le principal changement de la v7, selon la lettre de présentation, est que l'interface « utilise désormais une sémantique CREATE/MODIFY au lieu de SET ». Almeida écrit que cela permet « à la libc comme à l'application » d'utiliser des listes robustes « sans conflit ».

Opération dans la v7	Ce qu'elle fait
Create (32 ou 64)	Crée une nouvelle liste robuste et renvoie son index
Modify (32 ou 64)	Remplace la tête d'une liste existante
Modify avec une tête nulle	Libère l'emplacement de cette liste
List limit	Indique combien de listes un thread peut détenir

La série compte 10 correctifs. Elle a été adaptée au noyau mainline actuel. Almeida écrit qu'il a étendu les autotests des listes robustes et porté l'ancien appel système sur les nouveaux mécanismes internes. « Testé sur x86 et arm64 », indique la lettre de présentation.

Le travail attendait un autre correctif. La lettre de présentation explique qu'il reprend maintenant que « nous avons en grande partie corrigé la situation de concurrence op_pending ». Il s'agit d'un défaut dans la façon dont un déverrouillage en cours est enregistré. La documentation du noyau qualifie l'ancien mécanisme de déverrouillage de « racy ». La lettre de présentation ne cite aucune version cible du noyau.

Ce que cela signifie pour les développeurs

La plupart du code applicatif n'appellera jamais ces appels système directement. Les bibliothèques C et les émulateurs, si. Si vous maintenez une libc, un runtime de threads ou une couche de traduction, lisez dès maintenant la lettre de présentation de la v7. La conception en création et modification existe pour qu'une libc et une application puissent chacune posséder une liste sans s'écraser mutuellement. C'est précisément sur cette coordination que votre code s'appuierait.

Si vous distribuez un logiciel que l'on exécute sous FEX-Emu ou un traducteur Arm64 similaire, surveillez l'arrivée de cette série dans une version publiée du noyau. D'ici là, le code x86 32 bits sur Arm64 n'a toujours aucun moyen d'enregistrer des listes robustes dans son propre format.

Considérez ces détails comme provisoires. Il s'agit d'une proposition sur une liste de diffusion, pas de code intégré, et l'interface a déjà changé de forme entre la v6 et la v7. Ne développez pas en vous appuyant dessus avant qu'une version du noyau ne l'inclue.