Saltar al contenido

Las llamadas al sistema set_robust_list2 de Linux vuelven en v7 para FEX-Emu

Igalia publicó el 25 de septiembre de 2026 la v7 de las llamadas futex set_robust_list2, 10 meses después de la v6, para ayudar a FEX-Emu a ejecutar código x86 de 32 bits en Arm64.

Por Tech AI Wire Team

4 min de lectura

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, de la consultora Igalia, publicó el 25 de septiembre de 2026 la versión 7 de dos nuevas llamadas al sistema de Linux, set_robust_list2() y get_robust_list2(). Cierran un hueco que impide a emuladores como FEX-Emu manejar bien los bloqueos cuando ejecutan programas x86 de 32 bits en máquinas Arm64. Es la primera revisión nueva desde la v6 del 22 de noviembre de 2025.

Una llamada al sistema, o syscall, es la puerta fija que usa un programa para pedirle algo al kernel. Esta pareja va ya por su séptima versión.

Para qué sirve una lista de futex robustos

Un futex es un bloqueo que vive en la propia memoria de un programa. La documentación del kernel describe los futex como bloqueos que, cuando nadie más los quiere, «pueden adquirirse y liberarse desde el espacio de usuario sin entrar en el kernel». Eso los hace rápidos, y están debajo de los bloqueos de hilos corrientes, como los mutex de pthread.

El problema empieza cuando un hilo muere mientras todavía tiene un bloqueo. Los demás hilos podrían quedarse esperando para siempre. Una lista de futex robustos lo resuelve. Cada hilo mantiene una lista de los bloqueos que tiene y le dice al kernel dónde está esa lista. Normalmente la gestiona una biblioteca como glibc.

Cuando el hilo termina, el kernel «recorre la lista con cuidado», según la documentación. Marca cada bloqueo que tenía el hilo con el indicador FUTEX_OWNER_DIED y despierta a un hilo en espera. El siguiente hilo que toma el bloqueo sabe así que su dueño anterior murió a mitad de la tarea.

Por qué las llamadas antiguas fallan en Arm64

Hoy un hilo registra su lista con set_robust_list(). La cobertura de LWN de una versión anterior de este trabajo explicó dos límites. La llamada solo permite una lista por hilo. Además, supone que la lista usa el tamaño de puntero nativo de la máquina, que es de 64 bits en un sistema Arm64 o x86-64 moderno.

En x86-64, el kernel tiene un segundo punto de entrada de compatibilidad que entiende las listas de 32 bits de los programas x86 antiguos. Como dijo LWN, «no existe ese punto de entrada de compatibilidad para AArch64», el nombre formal del Arm de 64 bits. Así que un programa x86 de 32 bits que corre en un emulador sobre Arm64 no tiene dónde registrar sus listas en su propio formato.

FEX-Emu es uno de esos emuladores. Traduce programas Linux x86 y x86-64 para que funcionen en hardware Arm64, y es el caso de uso que citan los parches v7. Tech AI Wire publicó la semana pasada la explicación del propio proyecto sobre por qué la emulación x86 en Arm es costosa.

Qué cambia en la v7

Las nuevas llamadas permiten que un hilo tenga varias listas robustas, y cada lista declara si usa punteros de 32 o de 64 bits. El cambio principal de la v7, según la carta de presentación, es que la interfaz «ahora usa una semántica CREATE/MODIFY en lugar de SET». Almeida escribe que así «tanto la libc como la aplicación» pueden usar listas robustas «sin conflictos».

Operación en la v7Qué hace
Create (32 o 64)Crea una nueva lista robusta y devuelve su índice
Modify (32 o 64)Sustituye la cabeza de una lista existente
Modify con cabeza nulaLibera el hueco de esa lista
List limitIndica cuántas listas puede tener un hilo

La serie tiene 10 parches. Está adaptada al kernel mainline actual. Almeida escribe que amplió las pruebas automáticas de las listas robustas y trasladó la llamada antigua a los nuevos mecanismos internos. «Probado tanto en x86 como en arm64», dice la carta de presentación.

El trabajo esperaba otra corrección. La carta de presentación dice que se retoma ahora que «hemos corregido en gran parte la condición de carrera de op_pending». Es un fallo en cómo se registra un desbloqueo en curso. La documentación del kernel califica el mecanismo de desbloqueo antiguo de «racy». La carta de presentación no menciona ninguna versión del kernel como objetivo.

Qué significa esto para los desarrolladores

La mayor parte del código de aplicación nunca llamará directamente a estas syscalls. Las bibliotecas de C y los emuladores sí. Si mantienes una libc, un runtime de hilos o una capa de traducción, lee ya la carta de presentación de la v7. El diseño de crear y modificar existe para que una libc y una aplicación puedan tener cada una su lista sin pisarse. Esa coordinación es justo de lo que dependería tu código.

Si distribuyes software que la gente ejecuta con FEX-Emu o un traductor Arm64 parecido, vigila cuándo llega esta serie a una versión publicada del kernel. Hasta entonces, el código x86 de 32 bits en Arm64 sigue sin poder registrar listas robustas en su propio formato.

Toma los detalles como provisionales. Es una propuesta en una lista de correo, no código incorporado, y la interfaz ya cambió de forma entre la v6 y la v7. No desarrolles contra ella hasta que una versión del kernel la incluya.

Fuentes

  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

Artículos relacionados