Subject: port-mips/8762: sigreturn() vs. lazy FPU context switching problems
To: None <gnats-bugs@gnats.netbsd.org>
From: Klaus Klein <kleink@uni-trier.de>
List: netbsd-bugs
Date: 11/08/1999 02:54:44
>Number:         8762
>Category:       port-mips
>Synopsis:       sigreturn() vs. lazy FPU context switching problems
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-mips-maintainer (NetBSD/mips Portmasters)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov  8 02:54:00 1999
>Last-Modified:
>Originator:     Klaus Klein
>Organization:
Frobozz Magic Standards Company
>Release:        today
>Environment:
any NetBSD/mips


>Description:
	Note: the following observation is based on code inspection
	while doing some related work, so take this with a grain of salt.

	Consider the following scenario:

	1. an FPU-using process is sent a signal: sendsig() copies the
	   FPU context from the PCB to the sigcontext, preceeded by a
	   savefpregs() call to dump the FPU context to the PCB if necessary.

	   The process is no longer the FPU owner.

	2. From within the signal handler, the process is using the FPU.
	   Since it's no longer the FPU owner, a Coprocessor Unusable
	   Exception occurs; the FPU is made available to the process.

	   The process is the FPU owner again.

	3. The signal handler returns via sigreturn(), which copies the
	   previous FPU context from the sigcontext to the PCB. 
	   
	4. There are two control flows possible from this point, iff the
	   process is still the FPU owner:

	    i) If our process is next to use the FPU, it will still hold
	       the context from the signal handler, leading to the obvious
	       problem.

	   ii) If a different process is next to use the FPU, a Coprocessor
	       Unusable Exception occurs (since `our' process is still the
	       FPU owner); the FPU context, which is still the one from the
	       signal handler, is dumped to `our' process's PCB clobbering
	       the data copied in 3. and the outcome is similiar to i).

>How-To-Repeat:
	See above.

>Fix:
	If the observation is correct, this should be as simple as
	relinquishing the FPU ownership (i.e. using savefpregs() or
	an optimized version thereof without saving the register
	contents) before copying to the PCB, which appears to yield
	the behaviour originally intended.
>Audit-Trail:
>Unformatted: