Linus Torvalds a intégré le vendredi 21 août 2026 un correctif d'une ligne au pilote graphique Xe d'Intel, mettant fin à une anomalie qui laissait sa propre station de travail sur un écran noir avec le gestionnaire de session redémarrant en boucle. Le code fautif arrondissait vers le haut un décalage en mémoire vidéo là où il fallait arrondir vers le bas, ce qui remettait discrètement la zone de métadonnées de compression à l'allocateur comme si elle était libre. Y parvenir a demandé 24 correctifs de débogage et 18 démarrages du noyau, et Torvalds a décrit le processus comme une session de débogage infernale, énormément aidée par une intelligence artificielle qui lui a répété que le problème était insoluble.
The short answer
Linus Torvalds a intégré le commit 818bebeb63dd au pilote Xe d'Intel le 21 août 2026, corrigeant une anomalie qui laissait sa station Battlemage G21 sur un écran noir avec GDM en boucle. Le calcul du décalage flat CCS arrondissait vers le haut sur une frontière de 128 Kio au lieu du bas, si bien que de la mémoire appartenant à la zone de métadonnées de compression était remise à l'allocateur. La recherche a demandé 24 correctifs de débogage et 18 démarrages du noyau. Torvalds a crédité une intelligence artificielle de l'essentiel du travail mécanique, en notant qu'elle a répété que le problème était impossible.
Torvalds n'écrit plus beaucoup de correctifs lui même. Il intègre, il relit, il hausse parfois le ton. Alors quand un commit arrive avec son nom en ligne d'auteur et un message décrivant 18 démarrages et une session infernale, l'intérêt ne porte pas sur le correctif. Il porte sur la forme du problème qui l'a ramené devant le clavier.
Ce que faisait la machine
Un écran noir, et un gestionnaire de session qui redémarre indéfiniment. Voilà tout le symptôme visible, sur une carte Intel Battlemage G21 dotée de 16 Gio de mémoire vidéo.
En dessous, le compositeur effectuait sa première soumission graphique et cette soumission échouait. GDM fait la chose sensée quand une session meurt immédiatement, à savoir en démarrer une autre, et la boucle qui en résulte est impossible à distinguer d'une machine qui refuse simplement d'arriver au bureau. Aucune erreur ne s'affiche puisqu'il n'y a pas d'affichage.
Les pannes à ce point du démarrage sont désagréables à déboguer pour une raison structurelle : tout ce que vous utiliseriez normalement pour observer le système se trouve en aval de la chose cassée. Vous déboguez l'affichage depuis une machine sans affichage.
Le sens de l'arrondi
Les cartes Intel réservent une zone en haut de la mémoire vidéo pour le flat CCS, les métadonnées de compression qui permettent au matériel de compresser les tampons d'affichage et d'autres surfaces. Rien d'autre ne doit y toucher.
La fonction qui détermine le début de cette zone, get_flat_ccs_offset, calculait une adresse puis l'alignait sur une frontière de 128 Kio avec round_up. C'est le mauvais sens pour ce calcul précis, et la conséquence est nette : arrondir vers le haut le début d'une zone réservée déplace la frontière plus loin, ce qui rend la zone protégée plus petite que la vraie. Les octets situés entre le début réel de la zone et la frontière arrondie cessent d'être protégés.
L'allocateur de mémoire vidéo apprenait alors que ces octets étaient disponibles. Il les a distribués. Le compositeur a reçu de la mémoire que le matériel traitait simultanément comme des métadonnées de compression, et sa première soumission a échoué.
Remplacez round_up par round_down et la frontière se déplace dans l'autre sens, la zone protégée devient légèrement plus grande que strictement nécessaire, et rien au dehors ne peut être cédé. C'est tout le correctif.
Pourquoi cette catégorie de bogue est difficile
Les erreurs de sens d'arrondi sont fréquentes en code bas niveau, et elles le sont pour une raison qui n'a rien à voir avec la négligence.
Les deux fonctions existent parce que les deux sont nécessaires. Quand vous dimensionnez une allocation, vous arrondissez vers le haut, car il vous faut au moins cette place. Quand vous marquez la frontière d'une chose à laquelle il ne faut pas toucher, vous arrondissez vers le bas, car la zone protégée doit couvrir au moins la vraie. Les deux cas cohabitent dans les mêmes fichiers, les appels se lisent presque à l'identique, et un relecteur qui parcourt un diff ne dispose d'aucun signal local lui indiquant à laquelle des deux questions cette ligne répond.
Ensuite, la panne est non déterministe en pratique. Qu'un problème survienne dépend de l'endroit où le décalage calculé tombe par rapport à la frontière d'alignement, et du fait que l'allocateur vienne ou non piocher dans l'interstice. Certaines cartes vont bien. Certaines configurations vont bien jusqu'à ce qu'une taille de mémoire change. C'est ainsi que le défaut a franchi la relecture et atteint une version publiée plutôt que d'être attrapé par un banc de test.
La partie intelligence artificielle, à lire avec attention
Torvalds a crédité un modèle de l'essentiel du travail de force, et sa formulation mérite d'être citée plutôt que résumée. Il a parlé d'une session de débogage infernale, énormément aidée par une intelligence artificielle faisant une grande part du travail ingrat. Puis, immédiatement : il aimerait la qualifier d'assistante infatigable, mais le modèle a plusieurs fois affirmé catégoriquement que la chose était impossible. Et il soupçonne ces outils d'avoir été entraînés par des gens moins têtus que lui.
Les deux moitiés forment l'histoire. Le modèle a absorbé le coût mécanique de 24 passes d'instrumentation, une quantité de fastidieux considérable et exactement le travail qui pousse les gens à abandonner les bogues difficiles. Il a aussi produit un avis assuré selon lequel le problème était insoluble et qu'il valait mieux rédiger un rapport. Torvalds l'a ignoré et il avait raison.
Ce n'est pas un argument sur l'utilité des modèles pour le travail noyau. Torvalds a tranché sa propre position en juillet 2026 en disant que Linux n'est pas un projet anti intelligence artificielle et que l'outil se juge aux résultats, et le volume de correctifs assistés par modèle qui arrive sur les listes réseau a déjà rendu la question pratique plutôt que théorique. C'est un point plus étroit, sur le calibrage. Un modèle qui affirme qu'un problème est impossible a produit une sortie, pas un verdict, et ce problème là s'est révélé être un correctif d'un mot.
Ce qu'il faut en retenir
Si vous écrivez du code qui calcule le bord d'une zone que quelque chose d'autre ne doit pas utiliser, le sens de l'arrondi est une propriété de correction. Il mérite un commentaire au point d'appel indiquant de quel côté se trouve la sécurité, comme un verrou mérite une note sur ce qu'il protège. Mémoire graphique, fenêtres DMA, réservations de micrologiciel, alignement de partitions : la forme revient partout et le mode de panne est toujours le même, quelqu'un d'autre utilise discrètement de la mémoire qui devait rester interdite.
Et quand un bogue ne se bissecte pas proprement, la voie passe par la mesure plutôt que par la théorie. Vingt quatre correctifs et dix huit démarrages ne signalent pas que le processus a déraillé. C'est l'image du processus quand la réponse n'est pas devinable et que quelqu'un continue quand même.
Sources et pour aller plus loin
- Linus Torvalds Endures A Debug Session From Hell, Enormously Helped By AI, Phoronix, 21 août 2026
- Linus Torvalds Turns to AI to Track Down Intel Xe GPU Bug, Linuxiac, août 2026
- Linus Torvalds Endures A Debug Session From Hell, Slashdot, 21 août 2026
Questions fréquentes
Quelle était l'anomalie exactement ?
Les cartes graphiques Intel réservent une zone en haut de la mémoire vidéo pour le flat CCS, les métadonnées de compression qui font fonctionner la compression des tampons d'affichage. La fonction qui calcule le début de cette zone réservée, get_flat_ccs_offset, prenait l'adresse calculée et l'arrondissait vers le haut sur une frontière de 128 Kio. Arrondir vers le haut déplace la frontière plus loin : les octets situés entre le vrai début de la zone réservée et la frontière arrondie tombaient donc hors de ce que le pilote considérait comme réservé, et l'allocateur de mémoire vidéo était autorisé à les distribuer. Il l'a fait. La toute première soumission graphique du compositeur atterrissait alors sur de la mémoire que le matériel utilisait aussi comme métadonnées de compression, la soumission échouait, GDM relançait la session, et le tout bouclait. Le correctif consiste à arrondir vers le bas.
Pourquoi arrondir vers le bas est il le bon sens pour une zone réservée ?
Parce que les deux sens répondent à deux questions différentes et qu'il est facile de saisir la mauvaise. Quand vous dimensionnez une allocation, vous arrondissez vers le haut, car il vous faut au moins cette place. Quand vous marquez la frontière d'une zone à laquelle personne ne doit toucher, vous arrondissez vers le bas, car la zone protégée doit être au moins aussi grande que la vraie. Arrondir vers le haut l'adresse de début d'une zone réservée rétrécit la zone protégée, et tout ce qui se trouve entre le vrai début et le début arrondi devient un interstice que quelque chose finira par utiliser. C'est l'une des formes les plus courantes de bogue mémoire en code bas niveau, précisément parce que les deux appels compilent, que les deux paraissent raisonnables en relecture, et que la panne n'apparaît que si un allocateur donné vient piocher dans l'interstice.
Qui était touché ?
Le symptôme est apparu sur une carte Intel Battlemage G21 dotée de 16 Gio de mémoire vidéo, la machine qu'utilisait Torvalds. Le mode de panne est reconnaissable si vous le rencontrez : un écran noir et un gestionnaire de session qui redémarre sans fin, parce que le compositeur ne parvient pas à achever sa première soumission graphique. Qu'une carte donnée soit touchée dépend de l'endroit où tombe le décalage flat CCS par rapport à la frontière de 128 Kio et du fait que l'allocateur pioche ou non dans l'interstice, donc l'anomalie ne se reproduit pas sur toutes les configurations. C'est aussi ce qui l'a rendue difficile. Un bogue que seules certaines machines voient, sans relation évidente entre le matériel et le symptôme, est de ceux qui survivent à la relecture et atterrissent dans une version publiée.
Qu'a fait l'intelligence artificielle au juste ?
Du travail de force, selon les termes de Torvalds : ajouter de l'instrumentation, dérouler les résultats, et finalement rédiger le long message de commit. Ce qu'elle n'a pas fait, c'est trouver la réponse. Torvalds a écrit qu'il aimerait la qualifier d'assistante infatigable, mais que le modèle a plusieurs fois affirmé catégoriquement que la chose était impossible, et il ajoute qu'il soupçonne ces outils d'avoir été entraînés par des gens moins têtus que lui. C'est la lecture utile de cette histoire pour quiconque débogue avec un modèle. Il a comprimé le coût mécanique de 24 passes d'instrumentation, ce qui a une vraie valeur, et il a produit une conclusion assurée et fausse sur la faisabilité, ce qui constitue un vrai danger. Les deux se sont produits dans la même session.
Y a t il une leçon au delà du correctif lui même ?
Deux. La première porte sur l'instrumentation comme stratégie : quand un bogue ne se bissecte pas proprement, la voie consiste à ajouter de la mesure plutôt que des hypothèses, et 24 correctifs sur 18 démarrages sont l'image de ce travail mené sérieusement. La seconde porte sur l'arrondi dans tout code qui calcule le bord d'une zone réservée, qu'il s'agisse de mémoire graphique, d'une fenêtre DMA, d'une réservation de micrologiciel ou d'une table de partitions. Le sens est une propriété de correction, pas un choix de mise en forme, et il mérite un commentaire au point d'appel indiquant de quel côté se trouve la sécurité. Aucune des deux leçons n'est nouvelle. Toutes deux continuent d'être apprises cher.