Linux 7.3 borne à 120 secondes les appels runtime EFI qui gelaient des serveurs entiers
Un appel firmware EFI qui ne revient jamais bloquait jusqu’ici tout l’espace utilisateur d’une machine : le kworker restait coincé dans le firmware et verrouillait efi_runtime_lock jusqu’au reboot. Linux 7.3 ajoute un timeout de 120 secondes qui déclare le firmware « wedged » et transforme un gel silencieux en signal explicite dans dmesg.
16 juin 2026. Breno Leitao, développeur Debian et ingénieur noyau chez Meta, publie la version 3 d’une série de patches pour borner les appels runtime EFI. 23 août 2026. Les mises à jour EFI sont fusionnées dans le noyau Linux 7.3 en développement. 16 août 2026. Linux 7.2 sort avec ses propres améliorations d’I/O — mais sans ce garde-fou.
La nouveauté tient en une phrase : quand un appel runtime EFI reste bloqué dans le firmware, le noyau attendait indéfiniment. Désormais, il attend 120 secondes, puis déclare le firmware « wedged ». Derrière ce mot, il y a des semaines d’enquête sur des serveurs qui se figeaient sans laisser d’autre trace qu’un message de workqueue lockup.
Un verrou unique qui fige tout le système
Pour comprendre la portée du correctif, il faut suivre le chemin exact d’un appel runtime EFI. Ces services — lecture et écriture NVRAM, set_wakeup_time, gestionnaires ACPI PRM, accès à efivarfs — passent tous par un kworker dédié, efi_rts_wq. Quand l’un de ces appels part dans le firmware et que celui-ci ne revient jamais, le kworker reste coincé à l’intérieur de l’appel firmware.
Ce n’est pas un gel ordinaire. Le kworker ne peut pas être annulé, et l’appelant conserve efi_runtime_lock pendant toute la durée du blocage. La conséquence est mécanique : tous les appels runtime EFI suivants — efivarfs, écritures NVRAM, set_wakeup_time, gestionnaires ACPI PRM — s’empilent sur le sémaphore et restent en attente, ininterruptibles, jusqu’au redémarrage.
Leitao décrit le symptôme dans sa lettre de couverture : le PC et le LR pointent dans la mémoire du firmware des services runtime ; le firmware n’est jamais revenu ; le worker est resté bloqué à travers les rapports de workqueue lockup de 127 s, 157 s et 188 s, jusqu’à ce qu’un système de supervision externe finisse par rebooter la machine. Pour un opérateur, rien ne désigne le firmware : le même symptôme pourrait être attribué à des dizaines de blocages sans rapport.
Le firmware est en cause, pas le noyau
Le correctif ne répare pas le bug de firmware — c’est le territoire du constructeur. Ce qu’il change, c’est l’effet de bord. La série de Leitao ajoute un timeout sur les complétions des services runtime : passé 120 secondes, le noyau ne laisse plus l’appel pendre indéfiniment.
Ce seuil n’est pas arbitraire. Il est volontairement plus long que tout appel légitime plausible vers les services runtime EFI. Un appel qui dépasse 120 secondes est donc, par construction, un appel que le firmware n’a jamais rendu — pas un appel lent. La distinction est essentielle : elle évite de déclarer « wedged » un firmware simplement occupé sur une opération longue mais valide.
Ce qui se joue ici dépasse le cas d’un serveur isolé. À l’échelle d’une flotte, un gel attribué à tort à un sous-système quelconque — stockage, réseau, scheduling — déclenche des investigations coûteuses dans toutes les directions sauf la bonne. Le nouveau signal dmesg inverse la logique : au lieu d’un mystère de stalled task, on obtient un verdict non ambigu — « EFI firmware is at fault ». C’est le genre de message qui oriente un on-call vers le bon fournisseur en quelques secondes.
D’où vient le besoin : un serveur NVIDIA Grace
Le déclencheur concret est un incident sur un serveur NVIDIA Grace. Le matériel Arm récent, en particulier les plateformes destinées au calcul haute densité, dépend fortement du firmware pour les services runtime — plus qu’un serveur x86 classique. Quand le firmware de ces plateformes se comporte mal, le noyau n’a aucun moyen de reprendre la main sans ce type de garde-fou.
Le choix de Meta comme terrain d’expérimentation n’est pas anodin. L’entreprise exploite des flottes de serveurs à une échelle où un gel silencieux qui survient une fois tous les quelques mois par machine devient un flux constant d’incidents. C’est précisément le contexte que la lettre de couverture nomme « fleet scale » : à ce volume, un signal qui distingue le firmware des autres causes vaut son poids en heures d’ingénierie.
Le correctif a transité par la branche EFI du noyau, fusionnée le 23 août 2026 dans le cycle 7.3. Il s’ajoute à d’autres travaux du même cycle — nettoyage de la randomisation de pile, nouvelles API AES, support DRM élargi — mais il est l’un des rares dont la valeur est purement opérationnelle plutôt que fonctionnelle.
Ce que ça change pour un SRE
Le bénéfice immédiat est la réduction du rayon de souffle d’un bug firmware. Avant, un appel coincé emportait tout l’espace utilisateur avec lui ; après, il emporte au pire le timeout et produit un journal clair. Un host qui reboute tout seul devient un incident de firmware documenté, pas un mystère.
Le deuxième bénéfice est la détection. Le message dmesg explicite permet d’automatiser une alerte : plutôt que d’attendre qu’un système de supervision externe finisse par rebooter la machine après 127 s, 157 s ou 188 s de silence, on peut corréler le verdict « firmware wedged » avec le ticket constructeur correspondant, et compter les occurrences par modèle de plateforme.
Le troisième bénéfice est plus subtil : la précision du diagnostic réduit le temps moyen de résolution. Quand un on-call sait d’emblée que le firmware est fautif, il ne passe pas la nuit à écarter le stockage, le réseau ou l’ordonnanceur. Le timeout transforme un gel générique en un problème adressable.
Pourquoi les services runtime sont un angle mort
Les services EFI se découpent en deux familles. Les boot services n’existent que pendant le démarrage, puis le noyau prend la main et ils disparaissent. Les runtime services, eux, restent actifs pendant toute la vie du système : c’est par eux que passent les lectures NVRAM, le réglage de l’heure de réveil ou certains gestionnaires ACPI. C’est précisément parce qu’ils restent actifs qu’un bug firmware à cet endroit est si dangereux — et si difficile à corriger côté noyau.
Sur la plupart des serveurs, ces appels reviennent en microsecondes et passent inaperçus. C’est quand le firmware se bloque que la zone grise se révèle : le noyau ne peut ni annuler l’appel, ni reprendre la main, ni même distinguer un appel lent d’un appel mort. Le timeout de 120 secondes comble exactement cette ambiguïté, en choisissant un seuil qu’aucun appel légitime ne devrait atteindre.
Détecter le problème avant qu’il ne coûte un redémarrage tient en une commande :
dmesg -T | grep -iE "efi.*(wedged|timeout|fault)"Sur une flotte, ce filtre devient une alerte : une occurrence de « EFI firmware is at fault » doit ouvrir un ticket constructeur, pas une enquête noyau. L’incident devient enfin catégorisable, et c’est là toute la valeur du correctif pour un SRE.
Verdict
Si vous exploitez des serveurs Arm ou des flottes où des gels silencieux reviennent sans cause apparente, surveillez l’arrivée de Linux 7.3 et activez la journalisation dmesg de ces verdicts. Le garde-fou ne corrige pas votre firmware — mais il transforme une panne opaque en signal actionnable, et c’est déjà la moitié du chemin vers un ticket constructeur fermé.
Si vous êtes sur du matériel plus ancien ou stable, le correctif est transparent : le seuil de 120 secondes est au-dessus de tout appel légitime, donc rien ne change tant que votre firmware se comporte. Vous gagnez simplement un filet de sécurité que vous n’espériez pas devoir utiliser.
La leçon dépasse l’EFI. Un noyau qui attend indéfiniment un composant externe — firmware, driver, périphérique — cède le contrôle de sa propre disponibilité. Borner cette attente, c’est reprendre la main sur un système qu’on croyait geler de façon inexplicable.