Messages in this thread | | | Date | Mon, 10 Mar 2003 11:25:55 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [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 state).
> 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).
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |