That's what the patch does currently, and it works for the 'normal'
case. I believe saving the FPU state occurs as a high bandwidth
store (Intel and their design bugs). However, storing it on the
stack is horribly broken for the copy_from_user case where the
kernel thread might go to sleep and the saved state belongs to
another process. My thinking is that if we're going to have to
save state anyways, it might as well be put where it belongs so
that next time we want to do an fpu-fast-copy we won't have to save
state. (Looking at the normal use of a system, the FPU is only
touched by crt0.)
No, it works even if the kernel stuffs the FPU into the TSS due to the
sleep, because next time you switch back to that task:
switch_to(next)
/* restores perhaps bogus FPU state from in-progress MMX copy */
... MMX_copy()
...
restore_FPU()
/* now "correct" FPU state from stack is put into the FPU */
The user sees a consistant FPU state in all cases. You can even in
the MMX_copy() set last_task_used_math to NULL when you save the
state, and set it to 'current' after you reload the FPU before
returning from the MMX stuff.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu