Re: Need help in understanding x86 syscall

[Steven Rostedt <rostedt@goodmis.org>]

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/