Linus Torvalds et une IA trouvent le correctif d’une ligne pour un bug GPU Intel Xe

Une seule ligne de code a corrigé une panne sévère du pilote graphique Intel Xe sur du matériel Battlemage G21. Mais pour trouver cette ligne, Linus Torvalds et son assistant d’intelligence artificielle ont dû multiplier les hypothèses, les correctifs de diagnostic et les redémarrages du noyau Linux.

Le correctif : arrondir vers le bas, pas vers le haut

Le bug se trouvait dans le calcul de la frontière entre la mémoire vidéo classique — la VRAM — et une zone réservée au stockage flat Compute Command Streamer (CCS), utilisé notamment par le matériel de compression graphique.

Le changement revient conceptuellement à remplacer :

round_up(value, SZ_128K)

par :

round_down(value, SZ_128K)

Cette différence est déterminante. La valeur calculée indiquait la fin de la mémoire disponible pour l’allocateur VRAM. En l’arrondissant vers le haut, le pilote pouvait présenter comme libre une petite zone située au-delà de la limite réelle. Or cette zone appartenait aux métadonnées CCS et ne devait pas être utilisée pour des allocations ordinaires. L’arrondi vers le bas maintient au contraire l’allocateur du côté sûr de la frontière.

Comment une erreur d’alignement a corrompu le GPU

Une fois la zone CCS considérée à tort comme de la VRAM disponible, des allocations classiques pouvaient chevaucher puis écraser les métadonnées nécessaires au GPU. La corruption touchait notamment des données liées aux tables de pages et provoquait des artefacts à l’écran, des plantages du compositeur et le redémarrage en boucle de GDM, le gestionnaire d’affichage, sur les cartes Battlemage G21.

Le problème n’était donc pas qu’une simple erreur de calcul. Il s’agissait surtout d’une confusion sur le sens de la valeur : le code l’alignait comme s’il s’agissait d’une adresse de départ, alors qu’elle représentait une limite indiquant où s’arrêtait la mémoire utilisable. C’est ce décalage sémantique qui explique pourquoi un correctif minuscule a été si difficile à isoler.

24 correctifs de diagnostic et 18 démarrages

Torvalds a décrit l’enquête comme une « séance de débogage infernale ». Avec l’aide de l’IA, il a ajouté et modifié des instruments de diagnostic, suivi les calculs mémoire du pilote et comparé la position de la zone CCS signalée par le matériel avec la frontière transmise à l’allocateur VRAM.

Au total, il a fallu 24 versions de correctifs de débogage et 18 cycles de redémarrage et de test du noyau avant que l’erreur d’arrondi apparaisse clairement.

Ces redémarrages étaient essentiels : le problème se manifestait au niveau du matériel et du système d’affichage, pas uniquement comme une ligne de code suspecte. Chaque expérience permettait d’écarter d’autres explications possibles et de distinguer un problème d’allocation mémoire d’une défaillance plus générale du pilote graphique.

Une IA utile, mais loin d’être infaillible

Torvalds a utilisé l’assistant comme un partenaire de débogage interactif, et non comme un auteur autonome du correctif. L’outil a contribué à proposer des instruments de mesure, parcourir les chemins d’exécution et analyser les résultats des essais successifs. Il a ainsi pris en charge une grande partie du travail répétitif.

Mais l’assistant n’était pas une autorité fiable. D’après Torvalds, il a plusieurs fois conclu que le problème était impossible à résoudre et suggéré de rédiger simplement un rapport. C’est Torvalds qui a choisi l’expérience suivante, écarté les interprétations erronées et compris la portée de l’offset dans le modèle mémoire de l’allocateur.

C’est le point central de cette histoire : l’IA a généré des pistes et facilité les manipulations, tandis que l’expert a apporté le contexte technique, la persévérance, les tests vérifiables et le jugement final.

Le correctif a rejoint le noyau principal

Linus Torvalds a lui-même écrit et intégré le correctif du pilote Intel Xe dans le noyau Linux amont. Les informations disponibles indiquent que les séries stables encore maintenues devraient recevoir la modification via le processus habituel de rétroportage, mais les sources fournies ne permettent pas d’identifier avec certitude les versions stables concernées ni leurs dates de publication.

Il serait donc imprudent d’annoncer des numéros de versions précis. Les utilisateurs de matériel concerné devront vérifier les annonces de leur distribution Linux ou des mainteneurs du noyau pour confirmer qu’une version donnée contient bien le correctif.

Ce que cet épisode dit vraiment de l’IA dans le développement de Linux

Cette affaire ne constitue pas un blanc-seing pour le code généré par IA. Elle montre plutôt un usage ciblé et plus défendable : un développeur expérimenté peut employer une IA pour accélérer une boucle de débogage complexe, tout en restant responsable de l’hypothèse, de la conception des tests, de la revue et du correctif final.

Cela n’a rien à voir avec l’envoi de patchs ou de rapports de vulnérabilité générés automatiquement, non testés et dépourvus de véritable compréhension du sous-système concerné. Des mainteneurs du noyau ont décrit un « assaut » de contributions produites par des modèles de langage. Dans les sous-systèmes staging et réseau, certains responsables ont fait part de leur exaspération face à l’afflux de patchs de faible valeur ou mal compris.

Le chiffre souvent avancé d’une hausse de 2 700 % des soumissions doit toutefois être pris avec prudence : les informations disponibles ici ne précisent ni la méthode de mesure, ni la période étudiée, ni la catégorie exacte concernée. Ce qui est mieux établi est plus général : l’IA a réduit le coût de production du code et des rapports, mais leur examen et leur tri continuent de reposer sur les mainteneurs humains.

Torvalds a également expliqué que Linux n’était pas opposé par principe aux outils d’IA, notamment lorsqu’ils servent à la revue de code. Cette session de débogage Intel Xe en montre la limite concrète : l’IA peut être précieuse dans un processus d’ingénierie rigoureux, mais elle ne remplace ni la connaissance du sous-système, ni les tests reproductibles, ni la responsabilité humaine.

Le patch final ne faisait qu’une ligne. Le véritable exploit a consisté à savoir quelle ligne modifier — et à continuer de chercher lorsque l’assistant affirmait que la solution n’existait pas.