veilletech.fr
23 août Feed du jour
#02 IA Article

Linus débogue avec une IA qui abandonne

L'outil ne renonce pas tout seul : quelqu'un doit refuser d'arrêter.

Linus Torvalds corrige un bug du pilote Intel xe : une adresse de fin de mémoire utilisable arrondie vers le haut au lieu du bas, ce qui livrait à l'allocateur deux kilo-octets appartenant au matériel de compression. Il précise dans le commit que l'IA a fait le gros du travail ingrat, tout en déclarant plusieurs fois le problème insoluble.

4 min de lecturevidéo 1:12
Partager
Sommaire6 sections
  1. Ce qui se passe
  2. Le bug
  3. L'assertion qui ne pouvait pas échouer
  4. L'autre moitié du commit
  5. Ce que ça change
  6. À retenir

Ce qui se passe

Le 21 août, Linus Torvalds signe un commit sur le pilote graphique xe (Intel) intitulé « Don't hand out the flat CCS storage as usable VRAM ». Le correctif tient en un mot : un round_up() devient un round_down(). Le message de commit, lui, fait plusieurs paragraphes — et il vaut la lecture pour deux raisons distinctes.

Le bug

Le pilote appelle get_flat_ccs_offset() pour savoir où commence le stockage flat CCS, la zone que le matériel de compression utilise pour ses métadonnées. La fonction lit la base dans le matériel, la met à l'échelle selon le nombre de nœuds L3 activés, puis arrondit le résultat vers le haut, sur 128 Ko. Tout ce qui se trouve sous cet offset est ensuite remis à l'allocateur comme mémoire vidéo utilisable.

L'erreur est conceptuelle, et c'est ce qui la rend intéressante : arrondir vers le haut une limite qui signifie « la mémoire utilisable s'arrête ici » publie comme libre ce qui se trouve juste au-delà. Or la valeur mise à l'échelle n'a aucune raison d'être alignée sur 128 Ko. Sur une Battlemage G21 de 16 Gio, la base réelle et la base arrondie diffèrent de 2 Ko : ces deux kilo-octets de stockage CCS se retrouvent dans le pool de l'allocateur.

La suite est une chaîne de conséquences propre :

  1. le matériel de compression écrit dans cette zone sans page-table, sans buffer object et sans soumission GPU — et il le fait avant même que l'espace utilisateur existe ;
  2. sur la machine concernée, la table de pages de niveau 3 d'une VM Mesa atterrissait sur cette page à chaque démarrage à froid ;
  3. elle y perdait l'entrée couvrant le tas de batch-buffers du compositeur, qui fautait sur sa première soumission ; l'environnement de bureau redémarrait en boucle. Écran noir sur une machine par ailleurs saine.

Redémarrer la session suffisait à masquer le problème, puisque les tables de pages suivantes étaient allouées ailleurs — le genre de comportement qui rend un bug très difficile à cerner.

L'assertion qui ne pouvait pas échouer

Le détail le plus instructif est ailleurs. Une assertion existait pour attraper exactement ce cas : elle comparait l'offset à GSMBASE - ccs_size, par égalité. Cette valeur étant alignée sur 128 Ko, elle ne coïncide avec l'offset arrondi vers le haut que lorsque la base n'est pas alignée — c'est-à-dire précisément dans le cas qu'elle devait signaler. La vérification ne pouvait donc pas échouer quand il le fallait. Et elle n'était compilée qu'avec CONFIG_DRM_XE_DEBUG.

Le commit la remplace par une assertion qui, elle, peut échouer : le stockage CCS ne doit pas empiéter sur le GSM.

L'autre moitié du commit

Torvalds ajoute une note personnelle, et c'est elle qui a fait circuler le commit :

« Ce fut une session de débogage infernale, énormément aidée par une IA qui a fait une grande partie du travail ingrat. »

Il précise aussitôt la nuance : il aimerait parler d'assistant infatigable, mais l'IA a plusieurs fois affirmé que le problème était impossible et insoluble, et proposé d'écrire un rapport plutôt que de continuer. Il suppose que « ces choses ont été entraînées par des gens peut-être moins têtus » que lui.

Ce qui a fonctionné, en revanche, c'est la boucle : poussée par l'humain, l'IA a continué d'ajouter du code de débogage et d'en analyser fidèlement les résultats. Torvalds lui a d'ailleurs laissé rédiger le message de commit technique.

Le chiffre qui donne la mesure de l'effort : 24 patches de débogage successifs et 18 démarrages du noyau pour isoler un correctif d'un seul mot.

Ce que ça change

Trois lectures, toutes utilisables :

Le correctif est marqué Cc: stable@kernel.org : il remontera dans les noyaux maintenus.