Re: Need help in understanding x86 syscall

[Zachary Amsden <zach@vmware.com>]

Ukil a wrote:

>I had this question. As per my understanding, in the
>Linux system call implementation on x86 architecture
>the call flows like this int 0x80 -> syscall ->
>sys_call_vector(taken from the table)-> return from
>interrupt service routine. 
>  
>

Almost. There are two entry points, the one you describe above, and the 
sysenter entry point.


>Now I had the doubt that if the the syscall
>implementation is very large will the scheduling and
>other interrupts be blocked for the whole time till
>the process returns from the ISR (because in an ISR by
>default the interrupts are disabled unless “sti” is
>called explicitly)? That’s appears to be too long for
>the scheduling or other interrupts to be blocked? 
>Am I missing something here?
>  
>

There are 3 types of gates you can use to service interrupts / faults on 
i386. Task gates are used where complex state changes are required, and 
an assured state is needed, such as doublefault and NMI handlers. 
Interrupt gates are used where interrupts must be disabled during 
initial processing, such as the page fault gate. Trap gates are used 
when interrupts may be allowed, and do not clear the interrupt flag.

On Linux, syscall vector int 0x80 is a trap gate, which means interrupts 
are not disabled. The sysenter handler is very special; SYSENTER does 
disable interrupts, so if you look at sysenter_entry, one of the first 
things it will do is re-enable interrupts as soon as the stack is sane. 
Thus, interrupts are enabled by default during system call processing 
unless explicitly disabled.

Your analysis of what would happen otherwise is quite correct.

Zach