All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: linux-kernel@vger.kernel.org, Ukil a <ukil_a@yahoo.com>, 7eggert@gmx.de
Subject: Re: Need help in understanding  x86  syscall
Date: Thu, 11 Aug 2005 10:31:01 -0400	[thread overview]
Message-ID: <1123770661.17269.59.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.61.0508110954360.14541@chaos.analogic.com>

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



  reply	other threads:[~2005-08-11 14:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4Ae73-6Mm-5@gated-at.bofh.it>
2005-08-11 13:41 ` Need help in understanding x86 syscall Bodo Eggert
2005-08-11 14:04   ` linux-os (Dick Johnson)
2005-08-11 14:31     ` Steven Rostedt [this message]
2005-08-11 15:13       ` Coywolf Qi Hunt
2005-08-11 15:22         ` Steven Rostedt
2005-08-11 15:28         ` linux-os (Dick Johnson)
2005-08-11 15:51           ` Steven Rostedt
2005-08-11 16:19             ` Steven Rostedt
2005-08-11 16:31               ` Coywolf Qi Hunt
2005-08-11 16:59                 ` Coywolf Qi Hunt
2005-08-11 17:10                   ` linux-os (Dick Johnson)
2005-08-11 17:26                     ` Steven Rostedt
2005-08-11 17:33                       ` Steven Rostedt
2005-08-11 17:57                         ` linux-os (Dick Johnson)
2005-08-11 17:59                         ` Zachary Amsden
2005-08-11 18:17                           ` Steven Rostedt
2005-08-11 19:58                             ` Zachary Amsden
2005-08-11 20:04                               ` Steven Rostedt
2005-08-12 19:30                           ` Jan Engelhardt
2005-08-11 17:46                       ` linux-os (Dick Johnson)
2005-08-11 18:11                         ` Steven Rostedt
2005-08-11 18:21                           ` linux-os (Dick Johnson)
2005-08-11 19:00                             ` Steven Rostedt
2005-08-11 20:39                           ` Zwane Mwaikambo
2005-08-12 11:29                             ` Bodo Eggert
2005-08-11 17:18                   ` Steven Rostedt
2005-08-12  5:04                     ` Jeff Carr
2005-08-12  5:30                       ` Coywolf Qi Hunt
2005-08-12 10:34                       ` Steven Rostedt
2005-08-12 10:40                       ` Steven Rostedt
2005-08-11 14:05   ` Steven Rostedt
2005-08-11 23:25     ` Bodo Eggert
2005-08-11  5:39 Ukil a
2005-08-11 13:54 ` Steven Rostedt
2005-08-11 15:52 ` Zachary Amsden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1123770661.17269.59.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=7eggert@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=ukil_a@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.