Are x86 trap gate handlers safe for preemption?

Are x86 trap gate handlers safe for preemption?

[Mikael Pettersson]

Consider an exception handler like vector 7, device_not_available:

ENTRY(device_not_available)
        pushl $-1                       # mark this as an int
        SAVE_ALL
        movl %cr0, %eax
        testl $0x4, %eax                # EM (math emulation bit)
        jne device_not_available_emulate
        preempt_stop

Since this is invoked via a trap gate and not an interrupt gate,
what's preventing this code from being preempted and resumed on
another CPU before the read from %cr0? Another example is the
machine_check vector (also trap gate) whose handlers access MSRs.

I'm sure this actually works, but I don't see how.

/Mikael

Re: Are x86 trap gate handlers safe for preemption?

[Linus Torvalds]

In article <15808.17731.311432.596865@kim.it.uu.se>,
Mikael Pettersson  <mikpe@csd.uu.se> wrote:
>Consider an exception handler like vector 7, device_not_available:
>
>ENTRY(device_not_available)
>        pushl $-1                       # mark this as an int
>        SAVE_ALL
>        movl %cr0, %eax
>        testl $0x4, %eax                # EM (math emulation bit)
>        jne device_not_available_emulate
>        preempt_stop
>
>Since this is invoked via a trap gate and not an interrupt gate,
>what's preventing this code from being preempted and resumed on
>another CPU before the read from %cr0?

Well, since %cr0 should be stable across the task switche, that
shouldn't actually matter.

>				 Another example is the
>machine_check vector (also trap gate) whose handlers access MSRs.

This one looks like a real bug. The fix should be to make it an
interrupt gate, I suspect. Comments?

On the whole, I think it is probably a good idea to make all exceptions
be interrupt gates, and then on a case-by-case basis show why some don't
need to (ie clearly the system calls should _not_ be interrupt gates,
but we've long since made the page fault path use an interrupt gate for
similar special register stability reasons).

		Linus

Re: Are x86 trap gate handlers safe for preemption?

[george anzinger]

Linus Torvalds wrote:
> 
> In article <15808.17731.311432.596865@kim.it.uu.se>,
> Mikael Pettersson  <mikpe@csd.uu.se> wrote:
> >Consider an exception handler like vector 7, device_not_available:
> >
> >ENTRY(device_not_available)
> >        pushl $-1                       # mark this as an int
> >        SAVE_ALL
> >        movl %cr0, %eax
> >        testl $0x4, %eax                # EM (math emulation bit)
> >        jne device_not_available_emulate
> >        preempt_stop
> >
> >Since this is invoked via a trap gate and not an interrupt gate,
> >what's preventing this code from being preempted and resumed on
> >another CPU before the read from %cr0?
> 
> Well, since %cr0 should be stable across the task switche, that
> shouldn't actually matter.

Unless the new task does the same sort of thing... i.e.
touchs cr0 in some way.  The page fault issue was ok if the
intervening tasks did not fault...

-g
> 
> >                                Another example is the
> >machine_check vector (also trap gate) whose handlers access MSRs.
> 
> This one looks like a real bug. The fix should be to make it an
> interrupt gate, I suspect. Comments?
> 
> On the whole, I think it is probably a good idea to make all exceptions
> be interrupt gates, and then on a case-by-case basis show why some don't
> need to (ie clearly the system calls should _not_ be interrupt gates,
> but we've long since made the page fault path use an interrupt gate for
> similar special register stability reasons).
> 
>                 Linus

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

Re: Are x86 trap gate handlers safe for preemption?

[george anzinger]

Linus Torvalds wrote:
> 
> In article <15808.17731.311432.596865@kim.it.uu.se>,
> Mikael Pettersson  <mikpe@csd.uu.se> wrote:
> >Consider an exception handler like vector 7, device_not_available:
> >
> >ENTRY(device_not_available)
> >        pushl $-1                       # mark this as an int
> >        SAVE_ALL
> >        movl %cr0, %eax
> >        testl $0x4, %eax                # EM (math emulation bit)
> >        jne device_not_available_emulate
> >        preempt_stop
> >
> >Since this is invoked via a trap gate and not an interrupt gate,
> >what's preventing this code from being preempted and resumed on
> >another CPU before the read from %cr0?
> 
> Well, since %cr0 should be stable across the task switche, that
> shouldn't actually matter.

Unless the new task does the same sort of thing... i.e.
touchs cr0 in some way.  The page fault issue was ok if the
intervening tasks did not fault...

Cancel that!  Wrong page or book or...  Cr0 is the same for
all tasks so it is cool.
-g
> 
> >                                Another example is the
> >machine_check vector (also trap gate) whose handlers access MSRs.
> 
> This one looks like a real bug. The fix should be to make it an
> interrupt gate, I suspect. Comments?
> 
> On the whole, I think it is probably a good idea to make all exceptions
> be interrupt gates, and then on a case-by-case basis show why some don't
> need to (ie clearly the system calls should _not_ be interrupt gates,
> but we've long since made the page fault path use an interrupt gate for
> similar special register stability reasons).
> 
>                 Linus

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml