Move "used FPU status" into new non-atomic thread_info->status field.

Move "used FPU status" into new non-atomic thread_info->status field.

Post by Mikael Pettersso » Wed, 12 Mar 2003 03:00:16




>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.
...
>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.

Do you mean x87 control or the x87 stack here?

Quote:>(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).

Sorry for being dense, but can you clarify: will current 2.{2,4,5}
kernels preserve or destroy the parent process' FPU control at fork()?

We're using unmasked FPU exceptions on x86 (and Solaris/SPARC) in the
runtime system for the Erlang telecom systems programming language.
This gives a noticeable performance improvement, but it relies on
the FPU control not changing beneath it: the FPU control is only
initialised at startup and when SIGFPU has occurred.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Move "used FPU status" into new non-atomic thread_info->status field.

Post by Linus Torvald » Wed, 12 Mar 2003 03:10:08




> ...
> >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.

> Do you mean x87 control or the x87 stack here?

everything was random - the child would (if the fork() happened while the
parent had a lazy pending x87 state) get a random state from somebody
else.

HOWEVER: this only happens if the fork() actually has pending state on
that CPU, which is often not the case (if it has slept at all since the
last x87 op, or has been timesliced away etc, it won't have any pending
state on the CPU).

Quote:> >(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).

> Sorry for being dense, but can you clarify: will current 2.{2,4,5}
> kernels preserve or destroy the parent process' FPU control at fork()?

They're guaranteed to preserve the control state (it has to: you can't
just change the exception mask over a function call). However, that was
buggy at least in 2.5.x, and very possibly in 2.4.x too - haven't checked.

And since preserving the exception mask basically implies doing the whole
fxsave/fxrestor thing, in practice _everything_ is saved over fork() into
the child.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Move "used FPU status" into new non-atomic thread_info->status field.

Post by Mikael Pettersso » Wed, 12 Mar 2003 15:10:06


Quote:Linus Torvalds writes:

 > > Sorry for being dense, but can you clarify: will current 2.{2,4,5}
 > > kernels preserve or destroy the parent process' FPU control at fork()?
 >
 > They're guaranteed to preserve the control state (it has to: you can't
 > just change the exception mask over a function call). However, that was
 > buggy at least in 2.5.x, and very possibly in 2.4.x too - haven't checked.

Thanks. Our use of unmasked FPU exceptions should be safe then, unless
2.4 also has the bug you fixed in 2.5.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Move "used FPU status" into new non-atomic thread_info->status field.


   Date: Mon, 10 Mar 2003 18:20:35 +0000

Linus said, in a recent BK changelog:

        Also, fix x86 FP state after fork() by making sure the FP is unlazied
        _before_ we copy the state information. Otherwise, if a process did a
        fork() while holding the FP state lazily in the registers, the child
        would incorrectly unlazy bogus state.

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().

Are you preserving FPU state across fork() on x86?  If so, what do you
think might rely on this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. PPP callback

3. Mail system reporting "failed to fix up status field"

4. Auto kill of running jobs

5. return status of commands run in su - <name> -c "<command>"

6. Linux Con In Belgium

7. Does select return "read ready" or "won't block" status?

8. CERN 3.0 mkdir... can`t?

9. New: "can't resubmit intr status -19" when disconnecting USB device

10. New: Receiving "Bus master arbitration failure, status ffff" error

11. Help: use SED to move or replace "New-line" & "return" char

12. GETSERVBYNAME()????????????????????"""""""""""""