interrupt stack?

[asmboozer]

the UNIX internals said:

some machines provide a separate global interrupt stack used by all the handlers.

in machines without an interrupt stack, handlers run on the kernel stack of the currrent process.

they must ensure that the rest of the kernel stack is insulated from the handler.

this is in last page of 2.4.

I can not see it. why need to make sure the rest of the kernel stack is insulated from the handler?

if nothing do to ensure it. what will happen? an example would be more persuasive.

[Pype.Clicker]

"insulated" ? is that officially in the book ? (i'm just curious; i wouldn't have expected that term in that context).

I guess what they mean is that, even if the handler potentially can modify content on the kernel stack below it, it should refrain to do so otherwise things might go bad.

[asmboozer]

"insulated" ? is that officially in the book ? (i'm just curious; i wouldn't have expected that term in that context).

yes , it's the original words.

the kernel implements this by pushing a context layer on the kernel stack before calling the handler, this context layer, like a stack frame, contains the information needed by the handler to restore the previous execution context upon return.

the above is sentence after that.

I guess what they mean is that, even if the handler potentially can modify content on the kernel stack below it, it should refrain to do so otherwise things might go bad.

hi, would you give me an example of the potentiality?
thanks.


the tutorial of bran also write as that.

Code: Select all

/* All of our Exception handling Interrupt Service Routines will
*  point to this function. This will tell us what exception has
*  happened! Right now, we simply halt the system by hitting an
*  endless loop. All ISRs disable interrupts while they are being
*  serviced as a 'locking' mechanism to prevent an IRQ from
*  happening and messing up kernel data structures */
void fault_handler(struct regs *r)
{
    if (r->int_no < 32)
    {
        puts(exception_messages[r->int_no]);
        puts(" Exception. System Halted!\n");
        for (;;);
    }
}

isr_common_stub:
    pusha
    push ds
    push es
    push fs
    push gs
    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov eax, esp
    push eax
    mov eax, _fault_handler
    call eax
    pop eax
    pop gs
    pop fs
    pop es
    pop ds
    popa
    add esp, 8
    iret

i wonder whether I can rewrite it as

Code: Select all

/* All of our Exception handling Interrupt Service Routines will
*  point to this function. This will tell us what exception has
*  happened! Right now, we simply halt the system by hitting an
*  endless loop. All ISRs disable interrupts while they are being
*  serviced as a 'locking' mechanism to prevent an IRQ from
*  happening and messing up kernel data structures */
void fault_handler(struct regs *r)
{
    if (r->int_no < 32)
    {
        puts(exception_messages[r->int_no]);
        puts(" Exception. System Halted!\n");
        for (;;);
    }
}


isr_common_stub:
    call  _fault_handler   
    add esp, 8
    iret

if not, why? thanks much.

[Pype.Clicker]

Okay ...

When you call a function in another, there are couple of things the compiler can assume. First _he_ decided to do the call and it knows (by calling conventions) that some registers' state might be lost in the process and that others will be preserved by the callee.

In contrasts, an interrupt handler might interrupt anywhere in the code. If you were between "mov eax, 12345678" and "add eax, ebx" when the interrupt arises, having an interrupt handler that doesn't preserve the content of eax would make the interrupted code misbehave!

The other point is that you cannot tell in advance whether the interrupt will be handled while the processor was in user-level or kernel-level mode. If it was in user-level, it means you cannot rely on the values of DS, ES, and other segment registers: you need to save them aswell and reload the segments with kernel-friendly values (DPL0, etc.) during the interrupt handling.

Some of these considerations do not apply when you use e.g. a task gate in your IDT, in which case the CPU state is reset to some "default" values coming from the TSS, but this requires special tricks (a trash TSS) so that you can "return" from the interrupt without losing the pre-defined state during the switch back.

does it make bran's code clearer ?

[asmboozer]

Okay ...

When you call a function in another, there are couple of things the compiler can assume. First _he_ decided to do the call and it knows (by calling conventions) that some registers' state might be lost in the process and that others will be preserved by the callee.

In contrasts, an interrupt handler might interrupt anywhere in the code. If you were between "mov eax, 12345678" and "add eax, ebx" when the interrupt arises, having an interrupt handler that doesn't preserve the content of eax would make the interrupted code misbehave!

The other point is that you cannot tell in advance whether the interrupt will be handled while the processor was in user-level or kernel-level mode. If it was in user-level, it means you cannot rely on the values of DS, ES, and other segment registers: you need to save them aswell and reload the segments with kernel-friendly values (DPL0, etc.) during the interrupt handling.

Some of these considerations do not apply when you use e.g. a task gate in your IDT, in which case the CPU state is reset to some "default" values coming from the TSS, but this requires special tricks (a trash TSS) so that you can "return" from the interrupt without losing the pre-defined state during the switch back.

does it make bran's code clearer ?

thanks alot.