All of lore.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 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.