Re: [PATCH 2.5] clear USEDFPU in copy_thread

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux