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