FPSCR corruption

FPSCR corruption

[McMullan, Jason]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Oddity. I'm seeing SIGFPEs arrive in the wrong process.

I'm seeing this in my 2.4.x kernels, on 8260 and 750 cpus (and anything
else that has an FPU).

Example programs attached. Run 'someFPU' in an xterm. Run 'corruptFPSCR'
in another. Watch 'someFPU' die.

Is this a similar issue to the fast-syscall-return FPU path bug that
troubled the ia64 port?

(and yes, 'corruptFPSCR' is pathological, but so are most
denial-of-service exploits)

--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation

[-- Attachment #2: someFPU.c --]
[-- Type: text/x-c, Size: 271 bytes --]

#include <math.h>
#include <stdio.h>
#include <time.h>

int main(int argc, char * argv[])
{
	struct timespec sleeptime;
	sleeptime.tv_sec=0;
	sleeptime.tv_nsec=500000;

	while(1)
	{
		pow(2.0, 3.3);
		nanosleep(&sleeptime, NULL);
	}

	return 0;
}




[-- Attachment #3: corruptFPSCR.c --]
[-- Type: text/x-c, Size: 631 bytes --]

#include <math.h>
#include <stdio.h>
#include <signal.h>


#define fesetenv_register(env) \
        ({ double d = (env); asm volatile ("mtfsf 0xff,%0" : : "f" (d)); })


typedef union
{
    double fenv;
    unsigned long fpscr[2];
} my_fenv_union_t;

void sigfpeHandler(int x)
{
	// Do nothing.
	// The exception will be retrown forever...
	// until it affects another process ;-(
}

int main ()
{
	// Register to SIGFPE
	signal(SIGFPE, sigfpeHandler);

	// Force the generation of a SIGFPE
	my_fenv_union_t fenvt;
	fenvt.fpscr[1] = 0xffffffff;
	fesetenv_register(fenvt.fenv);

	return 0;
}

Re: FPSCR corruption

[Paul Mackerras]

> Oddity. I'm seeing SIGFPEs arrive in the wrong process.
>
> I'm seeing this in my 2.4.x kernels, on 8260 and 750 cpus (and anything
> else that has an FPU).

Hmmm, it doesn't fail for me, e.g. on a G4 cube (7400 cpu) running
2.4.23, or on a dual G5 running 2.6.7-rc2 ppc64.

We used to have a bug that would cause this but it got fixed quite a
while ago now.  What kernel version are you using?

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/