> On Thu, Feb 06, 2003 at 04:43:42PM -0800, Jun Sun wrote:
> > I am still curious whether this is a bug in i386 as well or they do
> > clear the flag in some non-obvious way. Note that the unlazy_fpu()
> > in copy_thread won't do it. It only clears the current process's
> > USEDFPU flag, while the child process's flag is set way back in
> > copy_flags() calls inside do_fork().
Well, I'm not an expert of linux/x86 at all, and this is a bit off
topic :), but look at the comment in arch/i386/process.c:408:
* We fsave/fwait so that an exception goes off at the right time
* (as a call from the fsave or fwait in effect) rather than to
* the wrong process. Lazy FP saving no longer makes any sense
* with modern CPU's, and this simplifies a lot of things (SMP
* and UP become the same).
It seems they're just calling unlazy_fpu to do a fsave/fwait to
synchronize the FPU so that if an exception happens in the FPU code of a
process, the current process is signalled and not some newly scheduled
process instead. I think they do the same thing when cloning; put a
barrier to current process FPU operations so that it gets the signal, not
its child, if something is wrong in the previously executed FPU
instructions. Whether TIF_USEDFPU is set or cleared in the child isn't
really relevant in fact, it is maybe slightly inefficient because on
the first context switch of the child, an unnecessary fsave/fwait will be
done, but it doesn't hurt.