All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: Vivien Chappelier <vivienc@nerim.net>
Cc: Ralf Baechle <ralf@oss.sgi.com>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [PATCH 2.5] FPU
Date: Mon, 27 Jan 2003 10:29:29 -0800	[thread overview]
Message-ID: <20030127102929.N11633@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0301260251300.15950-100000@melkor>; from vivienc@nerim.net on Sun, Jan 26, 2003 at 02:58:09AM +0100

On Sun, Jan 26, 2003 at 02:58:09AM +0100, Vivien Chappelier wrote:
> Hi,
> 
> 	At various places in the 2.5 kernel, the fpu is accessed in
> kernel mode with CU1 not set, causing an unexpected exception. This patch
> makes sure FPU can be accessed by the kernel, though it may only
> be a workaround. Any comment from someone with a better understanding of
> the FPU access/context switching code?
> 
> Vivien.
> 
> --- include/asm-mips64/fpu.h	2002-12-11 20:44:20.000000000 +0100
> +++ include/asm-mips64/fpu.h	2002-12-11 21:51:44.000000000 +0100
> @@ -109,6 +109,7 @@
>  
>  static inline void save_fp(struct task_struct *tsk)
>  {
> +	enable_fpu();
>  	if (mips_cpu.options & MIPS_CPU_FPU) 
>  		_save_fp(tsk);
>  }
> --- include/asm-mips/fpu.h	2002-12-11 20:44:20.000000000 +0100
> +++ include/asm-mips/fpu.h	2002-12-11 21:51:44.000000000 +0100
> @@ -109,6 +109,7 @@
>  
>  static inline void save_fp(struct task_struct *tsk)
>  {
> +	enable_fpu();
>  	if (mips_cpu.options & MIPS_CPU_FPU) 
>  		_save_fp(tsk);
>  }

The above two hunks seem to be right.

The following hunks are not right.  The checking for is_fpu_owner()
is meaningful.  If current process is FPU owner, you *don't* want to
do a restore which essentially wipe away the current FPU regsiter values
with an old snapshot of them.

I got a report saying save_fp_context() causes panic when current process
is FPU owner.  That tells me something is wrong in 2.5 that violates
that assumption that FPU is always enabled when current process is the
FPU owner.  I have it in my note and will look into it once I get to 2.5
work.  You are more than to look into it as well.  Meanwhile, just adding
a enable_fpu() to save_fp_context() should let you get rid of the crash.
(although I am afraid there might be other related bugs as this should
not be needed).

Jun

> --- arch/mips64/kernel/signal.c	2002-11-09 16:10:14.000000000 +0100
> +++ arch/mips64/kernel/signal.c	2003-01-14 01:35:42.000000000 +0100
> @@ -162,20 +162,19 @@
>  
>  	err |= __put_user(current->used_math, &sc->sc_used_math);
>  
> -	if (!current->used_math)
> -		goto out;
> +	if (current->used_math) {
> +
> +		/*
> +		 * Save FPU state to signal context.
> +		 * Signal handler will "inherit" current FPU state.
> +		 */
>  
> -	/*
> -	 * Save FPU state to signal context.  Signal handler will "inherit"
> -	 * current FPU state.
> -	 */
> -	if (!is_fpu_owner()) {
>  		own_fpu();
>  		restore_fp(current);
> +
> +		err |= save_fp_context(sc);
>  	}
> -	err |= save_fp_context(sc);
>  
> -out:
>  	return err;
>  }
>  
> --- arch/mips/kernel/signal.c	2002-11-09 16:10:08.000000000 +0100
> +++ arch/mips/kernel/signal.c	2003-01-14 01:36:41.000000000 +0100
> @@ -313,20 +313,19 @@
>  
>  	err |= __put_user(current->used_math, &sc->sc_used_math);
>  
> -	if (!current->used_math)
> -		goto out;
> +	if (current->used_math) {
> +
> +		/* 
> +		 * Save FPU state to signal context.
> +		 * Signal handler will "inherit" current FPU state.
> +		 */
>  
> -	/* 
> -	 * Save FPU state to signal context.  Signal handler will "inherit"
> -	 * current FPU state.
> -	 */
> -	if (!is_fpu_owner()) {
>  		own_fpu();
>  		restore_fp(current);
> +
> +		err |= save_fp_context(sc);
>  	}
> -	err |= save_fp_context(sc);
>  
> -out:
>  	return err;
>  }
>  
> --- arch/mips64/kernel/signal32.c	2002-11-09 16:10:14.000000000 +0100
> +++ arch/mips64/kernel/signal32.c	2003-01-14 01:34:52.000000000 +0100
> @@ -457,20 +430,19 @@
>  
>  	err |= __put_user(current->used_math, &sc->sc_used_math);
>  
> -	if (!current->used_math)
> -		goto out;
> +	if (current->used_math) {
> +
> +		/* 
> +		 * Save FPU state to signal context.
> +		 * Signal handler will "inherit" current FPU state.
> +		 */
>  
> -	/* 
> -	 * Save FPU state to signal context.  Signal handler will "inherit"
> -	 * current FPU state.
> -	 */
> -	if (!is_fpu_owner()) {
>  		own_fpu();
>  		restore_fp(current);
> +
> +		err |= save_fp_context(sc);
>  	}
> -	err |= save_fp_context(sc);
>  
> -out:
>  	return err;
>  }
>  
> 
> 

  parent reply	other threads:[~2003-01-27 18:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-26  1:58 [PATCH 2.5] FPU Vivien Chappelier
2003-01-26  3:35 ` Greg Lindahl
2003-01-28 10:33   ` Ralf Baechle
2003-01-27 18:29 ` Jun Sun [this message]
2003-01-29  1:26   ` Jun Sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030127102929.N11633@mvista.com \
    --to=jsun@mvista.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@oss.sgi.com \
    --cc=vivienc@nerim.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.