Re: Are x86 trap gate handlers safe for preemption?

[george anzinger]

Linus Torvalds wrote:
> 
> In article <[e-mail]>,
> Mikael Pettersson  <[e-mail]> 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   [e-mail]
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml