NetBSD Problem Report #8762

Received: (qmail 3726 invoked from network); 8 Nov 1999 10:52:37 -0000
Message-Id: <199911081052.LAA07112@i60s12.ira.uka.de>
Date: Mon, 8 Nov 1999 11:52:21 +0100 (CET)
From: Klaus Klein <kleink@uni-trier.de>
Reply-To: kleink@uni-trier.de
To: gnats-bugs@gnats.netbsd.org
Subject: sigreturn() vs. lazy FPU context switching problems
X-Send-Pr-Version: 3.95

>Number:         8762
>Category:       port-mips
>Synopsis:       sigreturn() vs. lazy FPU context switching problems
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    castor
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 08 02:54:00 +0000 1999
>Closed-Date:    Sun Jan 07 19:00:02 +0000 2001
>Last-Modified:  Sun Jan 07 19:00:02 +0000 2001
>Originator:     Klaus Klein
>Release:        today
>Organization:
Frobozz Magic Standards Company
>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.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: castor 
State-Changed-When: Thu Dec 28 18:10:36 PST 2000 
State-Changed-Why:  
I just checked in changes version 1.111 to src/sys/arch/mips/mips/mips_machdep.c 
and 1.20 of src/sys/arch/mips/mips/process_machdep.c which seem to fix 
this problem in my test case.  Klaus's analysis looks right. 


Responsible-Changed-From-To: port-mips-maintainer->castor 
Responsible-Changed-By: castor 
Responsible-Changed-When: Thu Dec 28 18:10:36 PST 2000 
Responsible-Changed-Why:  
I just checked in changes, so the feedback should probably go to me. 
State-Changed-From-To: feedback->closed 
State-Changed-By: kleink 
State-Changed-When: Sun Jan 7 10:59:10 PST 2001 
State-Changed-Why:  
Fix looks good to me - thanks! 
>Unformatted:

Home	PR Database Search