[lkml]   [2005]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: crash in entry.S restore_all, 2.6.12-rc2, x86, PAGEALLOC

On Thu, 7 Apr 2005, Dave Jones wrote:
> On Thu, Apr 07, 2005 at 07:47:41AM -0700, Linus Torvalds wrote:
> > So the sysenter sequence might as well look like
> >
> > pushl $(__USER_DS)
> > pushl %ebp
> > sti
> > pushfl
> > ..
> >
> > which actually does three protected pushes thanks to the one-instruction
> > "interrupt shadow" after an sti.
> Is this guaranteed on every x86 variant (or rather, every one
> that has SEP). ?

Well, since we only need two in this case, we don't care, but yes, it's
supposed to be guaranteed by anything that calls itself an x86.

In fact, we _do_ depend on it in a few other sequences. Notably

sti ; hlt

depends on the fact that an interrupt will always finish _after_ the hlt,
and we'll never halt before the hlt (and then re-execute the hlt after the
interrupt), and in

sti ; iret

where we depend on the fact that we don't get recursive interrupt stacks
(since we at that point have re-enabled the interrupt that happened).

Of course, if some future x86 decides that the interrupt shadow only
matters for special instructions (ie it's not so much a general interrupt
shadow as a "instruction combination"), I don't think Linux would care. I
really think there are only a very few valid sti-combinations, and I
suspect the above two are pretty much it.

(The other "magic" x86 behaviour is loading into the SS register, which
creates a one-cycle black hole after it. Linux shouldn't care, and in fact
nothing should care about it outside of old 16-bit non-protected-mode
programs, so I think that's another one that could be retired eventually)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.045 / U:24.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site