[lkml]   [2003]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BK-2.5] Move "used FPU status" into new non-atomic thread_info->status field.

On Mon, 10 Mar 2003, David S. Miller wrote:
> At least on sparc{32,64}, we consider FPU state to be clobbered coming
> into system calls, this eliminates a lot of hair wrt. FPU state
> restoring in cases such as fork().

We could _probably_ do it on x86 too. The standard C calling convention on
x86 says FPU register state is clobbered, if I remember correctly.
However, some of the state is "long-term", like rounding modes, exception
masking etc, and even if we didn't save the register state we would have
to save that part.

And once you save that part, you're better off saving the registers too,
since it's all loaded and saved with the same fxsave/fxrestor instruction
(ie we'd actually have to do _more_ work to save only part of the FP

> Are you preserving FPU state across fork() on x86? If so, what do you
> think might rely on this?

Probably nothing per se. HOWEVER, we'd still need to save the state for
rounding etc, so we might as well save it all.

As it was, the x86 state was pretty much random after fork(), and that can
definitely lead to problems for real programs if they depend on things
like silent underflow etc.

(Now, in _practice_ all processes on the machine tends to use the same
rounding and exception control, so the "random" state wasn't actually very
random, and would not lead to problems. It's a security issue, though).


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: 2005-03-22 13:33    [W:0.058 / U:3.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site