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 :
- 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 ;
- sur la machine concernée, la table de pages de niveau 3 d'une VM Mesa atterrissait sur cette page à chaque démarrage à froid ;
- 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 :
- Sur le fond technique : une garde qui ne peut pas échouer dans le cas qu'elle surveille est pire qu'une absence de garde, parce qu'elle donne le sentiment que le cas est couvert. Ça vaut bien au-delà du noyau.
- Sur les agents : la propension à conclure « c'est impossible » est un mode d'échec réel en session longue, pas une anecdote. Sur un problème dur, la valeur de l'outil se joue dans l'instrumentation répétitive, et c'est l'humain qui fournit l'obstination.
- Sur la traçabilité : le commit indique explicitement ce que l'IA a fait et ce qu'elle a rédigé. C'est une pratique d'attribution qui devient une norme utile.
Le correctif est marqué Cc: stable@kernel.org : il remontera dans les noyaux
maintenus.