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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |