FPU context and fork

FPU context and fork

[Krzysztof Helt]

I struggle to build a self-compiled toolchain and glibc for Sparcstation 
20 M612. I am running testsuite for both and I run into a failure from 
test-fenv test from glibc testsuite. This is a test of FP exceptions 
(IEEE 754 compliant) -each exception is disabled or enabled and checked 
if a handler is called when the exception is raised.

The test fails with 11 errors on UP kernel 2.4.27. This is probably 
incorrect as SuperSparc should be IEEE 754 compliant. But a problem is 
that it fails with 21 errors on SMP kernel 2.4.27. I suppose that a 
different behavior between UP and SMP version is a serious bug. I see it 
is done the same way in 2.6.10 series.

 I dug into a problem and found that it comes from not copying the FPU 
state in do_fork function. Actually, the FPU is disabled in every new 
created task and enabled later when the FPU operation is done. So the 
glibc test must have failed, because it enables or disables FP 
exceptions than forks and wait for the FP exception signal. After the 
fork, the FPU in the new task is initialized to a default state so 
rounding and exception settings are lost.

I also observed that a system of handling FPU context reloading is 
different in SMP and UP version.

I did a little research on Internet and found that FPU context 
initialization and reloading happened to other architectures (MIPS, SH) 
too. Various arguments were given how it should be done.

How  should it be done?  Should copy_flags() during do_fork() preserve 
FPU context/registers for child task? Should SMP and UP context 
switching be handled differently?

I am eager to fix this,
Krzysztof Helt

Re: FPU context and fork

[David S. Miller]

On Wed, 19 Jan 2005 20:48:37 +0100
Krzysztof Helt <krzysztof.h1@wp.pl> wrote:

> How  should it be done?  Should copy_flags() during do_fork() preserve 
> FPU context/registers for child task? Should SMP and UP context 
> switching be handled differently?

copy_thread(), via do_fork(), copies the FPU state in this code here:

#ifndef CONFIG_SMP
	if(last_task_used_math = current) {
#else
	if(current_thread_info()->flags & _TIF_USEDFPU) {
#endif
		put_psr(get_psr() | PSR_EF);
		fpsave(&p->thread.float_regs[0], &p->thread.fsr,
		       &p->thread.fpqueue[0], &p->thread.fpqdepth);
#ifdef CONFIG_SMP
		current_thread_info()->flags &= ~_TIF_USEDFPU;
#endif
	}

Re: FPU context and fork

[David S. Miller]

On Wed, 19 Jan 2005 21:46:40 +0100
Krzysztof Helt <krzysztof.h1@wp.pl> wrote:

> >#ifndef CONFIG_SMP
> >	if(last_task_used_math = current) {
> >#else
> >	if(current_thread_info()->flags & _TIF_USEDFPU) {
> >#endif
> >		put_psr(get_psr() | PSR_EF);
> >		fpsave(&p->thread.float_regs[0], &p->thread.fsr,
> >		       &p->thread.fpqueue[0], &p->thread.fpqdepth);
> >#ifdef CONFIG_SMP
> >		current_thread_info()->flags &= ~_TIF_USEDFPU;
> >#endif
> >	}
> >
> It is not enough or I do not understand something. The new thread will 
> have a _TIF_USEDFPU flag disabled (if not cleared here, it is cleared in 
> copy_flags() in the do_fork()). So, a FP disabled trap handler will 
> initialize FPU state from default values, not from the ones saved here. 
> BTW, the new thread is p or current in the copy_thread function? I 
> suppose it is current.

No, we are saving the "current" fpu state to the save area of "p" which
is the child thread.

Re: FPU context and fork

[Krzysztof Helt]

David S. Miller wrote:

>On Wed, 19 Jan 2005 20:48:37 +0100
>Krzysztof Helt <krzysztof.h1@wp.pl> wrote:
>
>  
>
>>How  should it be done?  Should copy_flags() during do_fork() preserve 
>>FPU context/registers for child task? Should SMP and UP context 
>>switching be handled differently?
>>    
>>
>
>copy_thread(), via do_fork(), copies the FPU state in this code here:
>
>#ifndef CONFIG_SMP
>	if(last_task_used_math = current) {
>#else
>	if(current_thread_info()->flags & _TIF_USEDFPU) {
>#endif
>		put_psr(get_psr() | PSR_EF);
>		fpsave(&p->thread.float_regs[0], &p->thread.fsr,
>		       &p->thread.fpqueue[0], &p->thread.fpqdepth);
>#ifdef CONFIG_SMP
>		current_thread_info()->flags &= ~_TIF_USEDFPU;
>#endif
>	}
>
>  
>
It is not enough or I do not understand something. The new thread will 
have a _TIF_USEDFPU flag disabled (if not cleared here, it is cleared in 
copy_flags() in the do_fork()). So, a FP disabled trap handler will 
initialize FPU state from default values, not from the ones saved here. 
BTW, the new thread is p or current in the copy_thread function? I 
suppose it is current.

Krzysztof