Est-ce que __alloc_pages_slowpath() est réentrant-sûr ou non?

Question

Un appel à __alloc_pages_slowpath() peut-il survivre à une interruption de périphérique qui appelle également __alloc_pages_slowpath() ou le deuxième appel corrige-t-il le premier?

Je vois un appel de programme en lecture (2) d'un fichier normal sur un système de fichiers XFS. La trace de la pile du noyau montre que finalement __alloc_pages_slowpath() est appelé, puis une IRQ e1000e arrive qui appelle finalement aussi __alloc_pages_slowpath() et ensuite un message de log "fooprog: échec d'allocation de page. Order: 0, mode: 0x4020" arrive presque immédiatement.

La trace toute la pile peut être vu ici: https://gist.github.com/790577

Answer 1

Le "fooprog: Page non allocation de quotas. 0, le mode: 0x4020" est dû à un problème de pilote e1000e. Définir vm.min_free_kbytes pour doubler sa valeur actuelle les empêche. __alloc_pages_slowpath() est probablement réentrant-sûr.

Mise à jour: (1) il est "normal" que des traces de pile énormes soient imprimées dans le journal système du noyau Linux lorsqu'un pilote de périphérique réseau tente d'allouer une page et ne le trouve pas. (2) quelqu'un a soumis un correctif et pendant six mois, il a été ignoré jusqu'à ce que je leur demande gentiment de suivre le patch. Après cela, le réseau KVM/qemu virtio a cessé de se bloquer lorsque les machines ont manqué de mémoire. (3) les alternatives à Linux sont malheureusement plus difficiles à utiliser pour faire un vrai travail.