BUG depuis deux versions du noyau de testing
Le
BERTRAND Jo=c3=abl

Bonjour à tous,
Est-ce que je suis le seul à avoir des problèmes avec les noyaux de
testing ? J'ai assez souvent la charge de mon serveur de test qui monte
à plus de 500 (!) avec une occupation CPU de 0 et les logs remplis de :
[226324.616534] BUG: Bad page map in process apache2 pte:00000080
pmd:1764cb067
[226324.616541] addr:00007f777c571000 vm_flags:08000070 anon_vma:
(null) mapping:ffff96792bf664a0 index:1c2
[226324.616593] file:mod_reqtimeout.so fault:ext4_filemap_fault [ext4]
mmap:ext4_file_mmap [ext4] readpage:ext4_readpage [ext4]
[226324.616597] CPU: 7 PID: 16832 Comm: apache2 Not tainted
4.14.0-3-amd64 #1 Debian 4.14.13-1
[226324.616598] Hardware name: System manufacturer System Product
Name/P8Q77-M2, BIOS 0224 08/17/2012
[226324.616599] Call Trace:
[226324.616609] dump_stack+0x5c/0x85
[226324.616614] print_bad_pte+0x1da/0x2a0
[226324.616617] unmap_page_range+0x7ce/0x9b0
[226324.616621] unmap_vmas+0x4c/0xa0
[226324.616625] exit_mmap+0x95/0x180
[226324.616630] mmput+0x54/0x140
[226324.616633] do_exit+0x287/0xb30
[226324.616636] ? handle_mm_fault+0xaa/0x1f0
[226324.616640] ? __do_page_fault+0x280/0x4e0
[226324.616642] do_group_exit+0x3a/0xa0
[226324.616645] SyS_exit_group+0x10/0x10
[226324.616649] system_call_fast_compare_end+0xc/0x6f
[226324.616651] RIP: 0033:0x7f77887a86d8
[226324.616652] RSP: 002b:00007ffd24a11318 EFLAGS: 00000246
[226324.616655] Disabling lock debugging due to kernel taint
[226324.694501] BUG: Bad rss-counter state mm:ffff967924cd6e40 idx:2 val:-1
[233970.944446] BUG: Bad page map in process sendmail-mta pte:00000080
pmd:1764cb067
[233970.944451] addr:00007f8907171000 vm_flags:08000070 anon_vma:
(null) mapping:ffff967987a86c50 index:94
[233970.944487] file:liblber-2.4.so.2.10.8 fault:ext4_filemap_fault
[ext4] mmap:ext4_file_mmap [ext4] readpage:ext4_readpage [ext4]
Aucun autre symptôme, pas de swap anormal. La machine en question est
un i7 3770 avec 16Go de mémoire. Pas d'erreur mémoire (memtest ne
renvoie strictement rien). Seule solution, redémarrer la machine.
Lorsque le système part en vrille comme ça, je me retrouve avec plus de
2000 processus (contre 300 à 350 en fonctionnement normal). Mais un ps
ne rend jamais la main, ce qui fait que je n'arrive même pas à isoler le
fautif. Je suspecte apache2 car le premier message d'erreur est toujours :
Bad page map in process apache2
Une idée ?
Bien cordialement,
JKB
Est-ce que je suis le seul à avoir des problèmes avec les noyaux de
testing ? J'ai assez souvent la charge de mon serveur de test qui monte
à plus de 500 (!) avec une occupation CPU de 0 et les logs remplis de :
[226324.616534] BUG: Bad page map in process apache2 pte:00000080
pmd:1764cb067
[226324.616541] addr:00007f777c571000 vm_flags:08000070 anon_vma:
(null) mapping:ffff96792bf664a0 index:1c2
[226324.616593] file:mod_reqtimeout.so fault:ext4_filemap_fault [ext4]
mmap:ext4_file_mmap [ext4] readpage:ext4_readpage [ext4]
[226324.616597] CPU: 7 PID: 16832 Comm: apache2 Not tainted
4.14.0-3-amd64 #1 Debian 4.14.13-1
[226324.616598] Hardware name: System manufacturer System Product
Name/P8Q77-M2, BIOS 0224 08/17/2012
[226324.616599] Call Trace:
[226324.616609] dump_stack+0x5c/0x85
[226324.616614] print_bad_pte+0x1da/0x2a0
[226324.616617] unmap_page_range+0x7ce/0x9b0
[226324.616621] unmap_vmas+0x4c/0xa0
[226324.616625] exit_mmap+0x95/0x180
[226324.616630] mmput+0x54/0x140
[226324.616633] do_exit+0x287/0xb30
[226324.616636] ? handle_mm_fault+0xaa/0x1f0
[226324.616640] ? __do_page_fault+0x280/0x4e0
[226324.616642] do_group_exit+0x3a/0xa0
[226324.616645] SyS_exit_group+0x10/0x10
[226324.616649] system_call_fast_compare_end+0xc/0x6f
[226324.616651] RIP: 0033:0x7f77887a86d8
[226324.616652] RSP: 002b:00007ffd24a11318 EFLAGS: 00000246
[226324.616655] Disabling lock debugging due to kernel taint
[226324.694501] BUG: Bad rss-counter state mm:ffff967924cd6e40 idx:2 val:-1
[233970.944446] BUG: Bad page map in process sendmail-mta pte:00000080
pmd:1764cb067
[233970.944451] addr:00007f8907171000 vm_flags:08000070 anon_vma:
(null) mapping:ffff967987a86c50 index:94
[233970.944487] file:liblber-2.4.so.2.10.8 fault:ext4_filemap_fault
[ext4] mmap:ext4_file_mmap [ext4] readpage:ext4_readpage [ext4]
Aucun autre symptôme, pas de swap anormal. La machine en question est
un i7 3770 avec 16Go de mémoire. Pas d'erreur mémoire (memtest ne
renvoie strictement rien). Seule solution, redémarrer la machine.
Lorsque le système part en vrille comme ça, je me retrouve avec plus de
2000 processus (contre 300 à 350 en fonctionnement normal). Mais un ps
ne rend jamais la main, ce qui fait que je n'arrive même pas à isoler le
fautif. Je suspecte apache2 car le premier message d'erreur est toujours :
Bad page map in process apache2
Une idée ?
Bien cordialement,
JKB
BERTRAND Joël
Si c'était le kernel, je dirais un rapport avec le bugs Intel sur le
calcul parallèle prédictif ? Un test en désactivant le patch je ne sais
plus comment au démarrage (je n'ai pas suivi de près).
Sinon pas d'idée, mais je ne suis pas un utilisateur intensif d'Apache.
Joël Bertrand, le 2018-05-02 :
J'utilise un noyau compilé maison, mais pas de problème de mon
côté du temps où il était en version 4.14.13. Je n'ai pas
l'usage d'Apache 2 par contre.
[...]
[...]
[...]
Apparemment, l'erreur rencontrée est suffisament sérieuse pour
teinter le noyau. Elle est provoquée lors de la montée en
mémoire du contenu de bibliothèques nécessaires au fonctionnement
d'apache2, ou tout du moins, du module concernant l'expiration
des requêtes... Mais peut-être aussi que tout ce qui se raporte
de près ou de loin à LDAP est concerné :
$ find /usr/lib/ -name 'liblber*'
[...]
/usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
$ dpkg -S /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
libldap-2.4-2:amd64: /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
Le problème ne viendrait donc pas de la mémoire, c'est toujours
ça de pris. Quand vous dites « aucun autre symptôme », le
service est-il toujours rendu par Apache ?
J'ai quelques idées de pertinence très inégale :
- Peut-être s'agit-il de problèmes de corruption de données sur
disque. Avez-vous eu l'occasion de contrôler l'état de la
partition système via fsck, ou l'état du ou des disques
sous-jacents ?
- Sinon, ça pourrait être un bug dans la pile d'appel au système
de fichier ext4, mais j'y crois moyennement. Le pilote ext4
n'a pas reçu de mise à jour particulière entre les noyaux
4.14.13 et 4.14.16 et étant donné sa large utilisation, ça se
serait probablement vu. Ou alors dans la gestion de la mémoire
virtuelle, ce qui pourrait expliquer le blocage de ps ?...
- Pour élargir un peu le spectre, est ce que les autres journaux
d'erreur mentionnent d'autres fichiers que mod_reqtimeout.so ou
liblber-2.4.so.2.10.8, ou bien est ce que toutes les erreurs
tournent autour de ces deux fichiers ?
Haricophile, le 2018-02-05 :
La remarque est pertinente étant donné la vitesse à laquelle les
patches ont dû être intégrés.
*À fin de débug* vous pouvez faire sauter le mécanisme en éditant
la commande de démarrage dans Grub. Appuyez sur E pour éditer,
puis modifiez la commande linux pour ajouter « pti=off » pour
faire sauter le mécanisme Kaiser, permettant de se prémunir
contre Meltdown, et « spectre_v2=off » pour couper les mécanismes
de Retpolines, permettant de se prémunir contre la seconde
variante de Spectre.
Si vous n'avez pas facilement la main sur la console au
démarrage, vous pouvez toujours placer ces options dans
/etc/default/grub, dans la variable GRUB_CMDLINE_LINUX et lancer
un update-grub.
Si le noyau est assez récent, vous pouvez contrôler l'état de
protection contre les vulnérabilités CPU comme suit:
$ grep . /sys/devices/system/cpu/vulnerabilities/*
Sinon, il est aussi possible de consulter le journal de démarrage
du noyau pour vérifier l'état des patches via la commande
suivante :
$ sudo dmesg | grep -i 'spectre|isolation'
*Rétablissez les patches de sécurité quand vous avez fini.*
À plus,
--
Étienne Mollier
Je ne sais pas, je n'ai pas eu l'idée de tester.
La machine est à 500 bornes, je ne peux pas faire cela facilement. Mais
je n'ai pas d'erreur dans les logs concernant les disques.
Non, rien d'autre.
Ça ne donne rien. Le noyau est un 4.14.0-3-amd64 #1 SMP Debian
4.14.13-1 (2018-01-14).
Root rayleigh:[/sys/devices/system/cpu] > dmesg | grep -i
'spectre|isolation'
[ 0.000000] Kernel/User page tables isolation: enabled
Cordialement,
JB
Joël Bertrand, le 2018-02-07 :
Intéressant, la piste d'un bloc défectueux stockant un morceau
de ces fichiers à l'air sérieuse. Est ce que vous pouvez
artificiellement déclencher le problème en lisant contenu de ces
fichiers, à coups de dd ou de base64 par exemple ?
# base64 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
Si besoin, vous pouvez retrouver la trace du fichier
mod_reqtimeout.so à coup de find :
# find / -xdev -name mod_reqtimeout.so
Je comprend. Si vous pouvez contacter du monde sur place pour
aider au dépannage, il se pourrait que ce ne soit pas du temps
perdu.
Si cette piste n'est pas concluante, alors je sèche. Il
resterait à tester les rustines contre les vulnérabilités des
processeurs, mais je ne suis pas convaincu.
D'accord, je m'en doutais, le répertoire n'est apparu qu'après
publication des correction de Spectre pour le noyau 4.14. On
peut toujours se fier à la sortie de dmesg néanmoins.
Kernel/User Page Table Isolation (PTI), le correctif contre
Meldown est actif. Ne coupez ce mécano que dans le cadre de
test!
Si vous voulez poursuivre sur la piste du patch PTI :
- Éditez /etc/default/grub pour modifier la variable comme suit :
GRUB_CMDLINE_LINUX="pti=off"
- Lancez la commande :
# update-grub
- Lancez un redémarrage de la machine :
# reboot
- Vérifiez l'activité du patch en consultant la sortie de :
# dmesg | grep isolation
À plus,
--
Étienne Mollier
Le fichier est parfaitement lisible (/usr est sur un disque en raid1 et
ça m'étonnerait que ce soit un problème de bloc défectueux, à la limite
un problème de système de fichiers...). Mais aucun des fichiers
incriminés n'est illisible.
Moi non plus...
Je vais attendre que cela se reproduise (si cela se reproduira, je
viens de passer les patches de buster qui viennent de me redémarrer
apache2 sur une dépendance de bibliothèque).
Cordialement,
JKB