En effet, cette chronique du travail d'Andy est véritablement passionnante !
De ce que j'ai compris de la problématique, je pense que ce problème pourrait se poser dans un système à micro-noyau.
En effet, les responsabilités du noyau sont certes limitées et dispersées dans des processus utilisateurs de l'espace utilisateur/non privilégié. Néanmoins, le micro-noyau lui même pourrait avoir le même type de problème si la pile noyau n'est pas mappée virtuellement à la mémoire. Cela dépend des choix d'implémentation.
La solution présentée dans cet article ne peut être mise en oeuvre que sur des architecture possédant une MMU. Les systèmes à noyau monolithique ou même à micro-noyau tournant sur des architectures sans MMU devront toujours faire face à ce problème, et procéder à l'ancienne pour détecter l'overflow (canaris, peinturer la pile, ..., ou dans le meilleur des cas utiliser une MPU si disponible, avec l'inconvénient de gâcher une page pour la garde).
[^] # Re: Micro-kernel
Posté par randruc . En réponse à la dépêche Sortie du noyau Linux 4.9. Évalué à 8.
En effet, cette chronique du travail d'Andy est véritablement passionnante !
De ce que j'ai compris de la problématique, je pense que ce problème pourrait se poser dans un système à micro-noyau.
En effet, les responsabilités du noyau sont certes limitées et dispersées dans des processus utilisateurs de l'espace utilisateur/non privilégié. Néanmoins, le micro-noyau lui même pourrait avoir le même type de problème si la pile noyau n'est pas mappée virtuellement à la mémoire. Cela dépend des choix d'implémentation.
La solution présentée dans cet article ne peut être mise en oeuvre que sur des architecture possédant une MMU. Les systèmes à noyau monolithique ou même à micro-noyau tournant sur des architectures sans MMU devront toujours faire face à ce problème, et procéder à l'ancienne pour détecter l'overflow (canaris, peinturer la pile, ..., ou dans le meilleur des cas utiliser une MPU si disponible, avec l'inconvénient de gâcher une page pour la garde).