public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Nyberg <alexn@telia.com>
To: Sergey Vlasov <vsu@altlinux.ru>
Cc: Rik van Riel <riel@redhat.com>,
	linux-kernel@vger.kernel.org, stian@nixia.no
Subject: Re: timer + fpu stuff locks up computer
Date: Sat, 12 Jun 2004 22:27:25 +0200	[thread overview]
Message-ID: <1087072045.707.54.camel@boxen> (raw)
In-Reply-To: <20040612184511.GD3396@sirius.home>

On Sat, 2004-06-12 at 20:45, Sergey Vlasov wrote:
> On Sat, Jun 12, 2004 at 07:14:22PM +0400, Sergey Vlasov wrote:
> > If the FPU state belong to the userspace process, kernel_fpu_begin()
> > is safe even if some exceptions are pending.  However, after
> > __clear_fpu() the FPU is "orphaned", and kernel_fpu_begin() does
> > nothing with it.
> > 
> > Replacing fwait with fnclex instead of removing it completely should
> > avoid the fault later.
> 
> Yes, it seems to be enough.  Another case where it looks like FPU
> might be "orphaned" is exit(); however, it is handled as a normal task
> switch, __switch_to() calls __unlazy_fpu(), which clears pending
> exceptions.
> 
> I'm still not sure what to do about possibly lost FP exceptions.  This
> can happen in two cases:
> 
> 1) Program calls execve() while an FP exception is pending.
> 
>    In this case clear_fpu() is called when the original executable is
>    already destroyed.  Even if we generate a SIGFPE in this case, it
>    would be delivered to the new executable.
> 
> 2) Program returns from a signal handler while an FP exception is
>    pending.
> 
>    In this case at clear_fpu() time restore_sigcontext() has already
>    wiped out all state of the signal handler, so the SIGFPE would
>    appear to be raised from the program code at the point where it was
>    interrupted by the handled signal.
> 
> Signed-Off-By: Sergey Vlasov <vsu@altlinux.ru>
> 
> --- linux-2.6.6/include/asm-i386/i387.h.fp-lockup	2004-05-10 06:33:06 +0400
> +++ linux-2.6.6/include/asm-i386/i387.h	2004-06-12 22:02:58 +0400
> @@ -48,10 +48,17 @@
>  		save_init_fpu( tsk ); \
>  } while (0)
>  
> +/*
> + * There might be some pending exceptions in the FP state at this point.
> + * However, it is too late to report them: this code is called during execve()
> + * (when the original executable is already gone) and during sigreturn() (when
> + * the signal handler context is already lost).  So just clear them to prevent
> + * problems later.
> + */
>  #define __clear_fpu( tsk )					\
>  do {								\
>  	if ((tsk)->thread_info->status & TS_USEDFPU) {		\
> -		asm volatile("fwait");				\
> +		asm volatile("fnclex");				\
>  		(tsk)->thread_info->status &= ~TS_USEDFPU;	\
>  		stts();						\
>  	}							\
> 

This works, tested also on a box with md and things looked fine.


Alex


  reply	other threads:[~2004-06-12 20:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-09 21:02 timer + fpu stuff locks my console race stian
2004-06-10 21:00 ` Matias Hermanrud Fjeld
2004-06-11  6:08   ` Lars Age Kamfjord
2004-06-12  2:53 ` Rik van Riel
2004-06-12  3:50   ` Rik van Riel
2004-06-12 13:44     ` Sergey Vlasov
2004-06-12 13:57       ` stian
2004-06-12 14:28         ` Sergey Vlasov
2004-06-12 14:25       ` timer + fpu stuff locks up computer Alexander Nyberg
2004-06-12 14:42         ` stian
2004-06-12 15:20           ` martin capitanio
2004-06-12 16:15             ` stian
2004-06-12 15:14         ` Sergey Vlasov
2004-06-12 18:45           ` Sergey Vlasov
2004-06-12 20:27             ` Alexander Nyberg [this message]
2004-06-12  4:35   ` timer + fpu stuff locks my console race Matt Mackall
     [not found] <26h3z-t3-15@gated-at.bofh.it>
     [not found] ` <26hGq-Zr-29@gated-at.bofh.it>
     [not found]   ` <26isF-1Im-11@gated-at.bofh.it>
     [not found]     ` <26lJU-4lC-23@gated-at.bofh.it>
2004-06-12 22:08       ` timer + fpu stuff locks up computer Andi Kleen
2004-06-13 13:06         ` Sergey Vlasov

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=1087072045.707.54.camel@boxen \
    --to=alexn@telia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=stian@nixia.no \
    --cc=vsu@altlinux.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox