linux-mips
[Top] [All Lists]

Re: [PATCH 2.5] clear USEDFPU in copy_thread

To: Jun Sun <jsun@mvista.com>
Subject: Re: [PATCH 2.5] clear USEDFPU in copy_thread
From: Vivien Chappelier <vivienc@nerim.net>
Date: Fri, 7 Feb 2003 23:13:16 +0100 (CET)
Cc: linux-mips@linux-mips.org
In-reply-to: <20030207104621.L13258@mvista.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
> 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.


<Prev in Thread] Current Thread [Next in Thread>