[Kos-dev] Double fault : ca continue

[Christophe Avoinne (Club-Internet)]

> **** Mail recent de Hlide (hier) ******
> Thomas posait la question :
> > mais pourtant ils arrivent a faire marcher linux et windows sous bochs.
> > alors comment font-ils ?
> et Hlide repondit :
> Parce que ni Linux ni Windows ne se trouvent réellement dans cette
> situation
> quand tu les lances (ce serait un bug majeur dans la conception du OS),
> car
> c'est pour un cas normalement non envisageable.
> ****** Fin mail de Hlide **************
>
> ****** Questions d'une personne sur la pmode-l, et reponses par Leif
> **************
> > I have some doubts about cpl0 stack and page fault.
> >
> > In the existing OS, can the task's cpl0 stack cause a page fault?
>
> I don't think so. We had a discussion about that a while ago. It will
> cause a double-fault instead of a page-fault. In a segmented OS,
> you will get a stack-fault instead of a double-fault. If you handle this
> stack-fault with a task, it's possible (but not a good idea) to expand
> the stack.
>

NON ! je signale qu'on tourne dans une architecture avec SEGMENTATION même
si on utilise pas le quart des instructions pourvues à cet effet. Voir ma
réponse à propos du Stack Fault. Pour que le StackFault ait lieu il faut
limiter la taille du sélecteur SS à la taille de la pile de la tâche noyau.
Or on ne pourrait plus utiliser les "mov %0,imm(%ebp,...)" avec des offsets
en dehors de cette limite car ces instructions utilisent implicitement SS,
donc à prohiber coûte que coûte cette option. GCC utilisent le registre
%ebp, comme un registre général quand on utilise
l'option -fomit-frame-pointer.

> > If not, the cpl0 stack is limited and can't be expanded.
>
> It's not, but you better not expand it.
>
> > Worst, this
> > mem area must be blocked even so the task is suspend or something,
> > right?
>
> If cpl0 stack overflows, you better terminate the offending app or
> let the OS "panic".
>

OUI, c'est une autre option, on décide que la tâche noyau a une pile de
certaine taille et qu'elle n'en changera pas.

Le problème, en revanche, c'est pour les IRQ qui peuvent provoquer ce double
page fault dans une tâche noyau : là il y a un réel soucis de faire
fonctionner quand même ce IRQ qui ne doit pas sentir coupable à cause de la
gourmandise de la tâche noyau.

Donc à réfléchir...

> > Suppose that a cpl0 code is running. And the next push to the stack
> > will cause a page fault.
> >
> > Suppose too that the system's page fault handler runs in a new task.
> > (It uses a task gate in the IDT)
>
> You shouldn't run page-fault handler in a new task. It should run in the
> contents of the current task. Double-fault and stack fault shoud be
> run in a new task.
>
> > In this scenery, what will happen if a hardware interruption occurs?
>
> It would be lost. That's one reason not to allow the cpl0 stack to
> expand. Another is that you want be able to catch recursive loops
> in cpl0 code that causes cpl0 stack overflows.
>
> > Will the system lose the interruption?
>
> Yes, but using the error codes you know the cause of the exception
> and the int number in case of an interrupt error, so you could
> re-invoke a failed interrupt. I don't know if this information would be
> available if you get a double-fault, but for stack-fault it would be
> possible to re-invoke the interrupt.
>

Impossible en fait... car on peut rien sauvegarder concernant l'interruption
hardware, puisque justement on ne parvient pas à le sauver sur la pile. A
moins que, dès qu'on exécute le double fault (autre TSS avec pile valide),
l'interruption peut avoir nouveau lieu. Ou après cette interruption. A
vérifier en mettant un "hlt" après un ESP non valide. Quant au stack
fault... il nous sied pas du tout. La question est de savoir si le signal
d'interruption d'IRQ est maintenu durant le processus des exceptions.

M'est avis qu'il faudra le considérer au début comme un défaut de conception
apparaissant dans le code de la tâche noyau incriminée et donc la traiter en
évitant de pénaliser tout le système. Si le problème des IRQ est
"résolvable", alors on peut envisager une expansion possible de la pile,
même si ça complique au final les choses.