Tout commence en avril 2016 lorsqu'un SIOU (Serious Industrial OCaml User), comme il les appelle, le contacte en privé pour lui signaler un bug dans un de leur logiciel : ce dernier subit des erreurs de ségmentation de manière aléatoire après un certain temps. Il n'arrive pas à reproduire le bug sur sa propre machine et le côté aléatoire du bug lui fait soupçonner un problème matériel chez le client (RAM défectueuse, surchauffe…). Il leur propose de tester leur mémoire et de désactiver l'hyperthreading, la mémoire était bonne mais il ne teste pas la désactivation (ce qui aurait résolu le problème).
De son côté le client fait ses tests et aboutit aux résultats suivants : le bug est présent avec la version 4.03 mais pas 4.02.3 du compilateur OCaml, avec GCC mais pas Clang (le runtime OCaml est en C), sur Linux et Windows mais pas OSX (ce qui se comprend, ce dernier utilisant Clang). Les coupables semblent identifiés : OCaml 4.03 et GCC, et le client suppose qu'il y a une erreur dans le code C du runtime.
Début mai 2016, le client offre un accès à leur machine à Xavier Leroy pour qu'il puisse identifier le problème. Il analyse des dumps post-plantage, voit bien des problèmes avec le ramasse-miette mais ne comprend pas ce qui peut causer un tel comportement dans son code. Il fait alors des tests en lançant le programme en parallèle (1, 2, 4, 8 ou 16 instances) et là tout devient clair : pas de bug quand l'hyperthreading n'est pas utilisé. Ils font des tests en le désactivant dans le BIOS et le problème ne se manifeste plus.
Cela aurait pu en rester là : le client était satisfait de pouvoir utiliser une version du runtime avec Clang, et Xavier Leroy ne sachant pas comment signaler le problème à Intel en reste là. Mais, début 2017, un autre SIOU fait un rapport de bug sur le tracker OCaml. Les symptomes étaient similaires et la discussion sur le ticket fut la suivante :
- douze heures après l'ouverture, une des ingénieurs précise que tous les ordinateurs qui ont pu reproduire le bug ont un CPU de la famille Skylake ;
- le lendemain, Xavier Leroy signale son expérience passée et propose de désactiver l'hyperthreading ;
- le jour suivant, un autre ingénieur du SIOU rapporte qu'en désactivant l'hyperthreading le problème disparaît ;
- en parallèle, il constate que si le runtime est compilé avec
gcc -O1 et non gcc -O2 alors le bug disparaît. Ce qui permet de comprendre pourquoi cela apparaît avec la version 4.03 qui est celle inaugurant l'option -O2 par défaut pour le runtime ;
- Mark Shinwell contacte des collègues chez Intel et s'occupe de rapporter le problème au support client de Intel.
Enfin, 5 mois plus tard, Debian publie une mise à jour du microcode des CPU Intel et Intel publie, en avril, une mise à jour des spécifications de la 6e génération de ses CPU. On trouve à la page 65 de ce document une mention du problème SKL150 qui était à l'origine de tous ces bugs, présenté en ces termes chez Debian :
SKL150 - Short loops using both the AH/BH/CH/DH registers and
the corresponding wide register *may* result in unpredictable
system behavior. Requires both logical processors of the same
core (i.e. sibling hyperthreads) to be active to trigger, as
well as a "complex set of micro-architectural conditions"
Pour ceux que cela intéresse et qui comprennent l'assembleur (ce qui n'est pas mon cas), le problème venait de ce bout de code du GC OCaml :
hd = Hd_hp (hp);
/*...*/
Hd_hp (hp) = Whitehd_hd (hd);
Qui après expansion des macros donne :
hd = *hp;
/*...*/
*hp = hd & ~0x300;
Avec Clang, cela donnait :
movq (%rbx), %rax
[...]
andq $-769, %rax # imm = 0xFFFFFFFFFFFFFCFF
movq %rax, (%rbx)
Tandis que le code optimisé de GCC donnait :
movq (%rdi), %rax
[...]
andb $252, %ah
movq %rax, (%rdi)
Qui pouvait lever le bug du CPU s'il se trouvait dans une petite boucle.
Ce bug sur ces CPU impacte tous les systèmes d'exploitation. Le correctif du micro-code pour la génération Skylake existe donc depuis avril, car Intel distribue ses mises à jour à toutes et tous, permettant aux mainteneurs des distributions de réaliser l'empaquetage et de rendre disponible cette mise à jour.
Cependant il n'en va pas de même pour la génération Kaby Lake, pour laquelle Intel ne distribue ses correctifs de micro-codes qu'aux seuls constructeurs ou assembleurs. Il résulte de cette situation une grande disparité des disponibilités pour cette mise à jour : certains constructeurs l'ont déjà proposée, d'autres ne le font pas.
Au final, il semblerait que Skylake se soit transformé en Skyfall et que la légendaire crainte gauloise que le ciel leur tombe sur la tête était fondée ! :-D
