Les changements EFI intégrés à Linux 7.3 limitent à 120 secondes l’attente de fin d’un appel mis en file. À expiration, le noyau désactive les services EFI d’exécution. Il contient l’attente, sans transformer l’opération défaillante en réussite.
Ce qui change à l’échéance
L’intégration EFI du 23 août inclut le travail de Breno Leitao. Le code intégré fixe 120 secondes pour cette attente, efface EFI_RUNTIME_SERVICES à expiration et renvoie EFI_ABORTED. Les appels suivants rencontrent des services désactivés au lieu de réutiliser le travail bloqué.
Le rapport initial décrit un firmware ne rendant jamais la main sur un serveur Grace. Le worker entré dans ce firmware ne peut pas simplement être annulé. Un traitement supplémentaire le retire si l’appel finit par revenir.
Une frontière pour contenir la panne
Imaginons deux tâches de maintenance. A entre dans une opération EFI qui se bloque ; B demande ensuite une autre opération EFI. Auparavant, l’attente derrière A pouvait être indéfinie. Avec ce nouveau chemin, l’attente de fin expire et les accès EFI ultérieurs échouent puisque les services sont désactivés.
C’est une information plus exploitable, mais la modification demandée par B n’a toujours pas eu lieu. Un changement d’ordre de démarrage ne doit pas être déclaré réussi au seul motif que le processus s’est terminé. Un service dépendant des appels firmware peut rester dégradé tandis que des charges indépendantes continuent.
Les 120 secondes concernent cette attente de fin, pas toutes les voies d’exécution du firmware ni une limite totale pour toute application. Attentes ailleurs, retards d’ordonnancement et autres défauts firmware restent des questions distinctes.
Conserver les éléments nécessaires à la réparation
Dans le compte rendu d’incident, séparez diagnostic du noyau, opération déclenchante, version du firmware et résultat vu par l’outil appelant. Conservez le journal pertinent et l’identification matérielle avant une action de reprise planifiée. Tout avertissement générique de workqueue ne désigne pas ce bug.
Comparez les machines par version de firmware et build du noyau, y compris les correctifs rétroportés par la distribution. Une étiquette de release candidate n’est pas une consigne de remplacement d’un noyau en production. La limitation intégrée et une correction du firmware agissent à des niveaux différents. Aucune variable EFI n’a été modifiée pour préparer l’article.
Revue du 8 septembre : sources primaires et évolutions vérifiées, explications et illustrations reprises.