Messages in this thread | | | Subject | Re: Need help in understanding x86 syscall | From | Steven Rostedt <> | Date | Thu, 11 Aug 2005 10:31:01 -0400 |
| |
On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote: > Every interrupt software, or hardware, results in the branched > procedure being executed with the interrupts OFF. That's why > one of the first instructions in the kernel entry for a syscall > is 'sti' to turn them back on. Look at entry.S, line 182. This > occurs any time a trap occurs as well (Page 26-168, i486 > Programmer's reference manual). FYI, this is helpful when > designing/debugging complex interrupt-service routines since > you can execute the interrupt with a software 'INT' instruction > (with the correct offset from the IRQ you are using). The software > doesn't 'know' where the interrupt came from, HW or SW.
I'm looking at 2.6.13-rc6-git1 line 182 of entry.S and I don't see it. Must be a different kernel.
According to the documentation that I was looking at, a trap in x86 does _not_ turn off interrupts.
In arch/i386/kernel/traps.c: trap_init
set_system_gate(SYSCALL_VECTOR,&system_call);
(where SYSCALL_VECTOR is of course 0x80).
This sets up a trap:
static void __init set_system_gate(unsigned int n, void *addr) { _set_gate(idt_table+n,15,3,addr,__KERNEL_CS); }
since type 15 makes this a trap (3 gives it user access). Also looking at the code that it will call:
ENTRY(system_call) pushl %eax # save orig_eax SAVE_ALL GET_THREAD_INFO(%ebp) # system call tracing in operation /* Note, _TIF_SECCOMP is bit number 8, and so it needs testw and not testb */ testw $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),TI_flags(%ebp) jnz syscall_trace_entry cmpl $(nr_syscalls), %eax jae syscall_badsys syscall_call: call *sys_call_table(,%eax,4) movl %eax,EAX(%esp) # store the return value syscall_exit: cli # make sure we don't miss an interrupt # setting need_resched or sigpending # between sampling and the iret
I don't see a sti here.
-- Steve
- 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/
| |