Messages in this thread | | | Date | Thu, 11 Aug 2005 08:52:32 -0700 | From | Zachary Amsden <> | Subject | Re: Need help in understanding x86 syscall |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |