FPSCR corruption

["McMullan, Jason" <jason.mcmullan@timesys.com>]

[-- 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;
}