Re: Need help in understanding x86 syscall

Steven Rostedt
2005-08-11T14:31:11Z

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