public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sergey Vlasov <vsu@altlinux.ru>
To: Alexander Nyberg <alexn@telia.com>
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:45:11 +0400	[thread overview]
Message-ID: <20040612184511.GD3396@sirius.home> (raw)
In-Reply-To: <20040612151422.GC3396@sirius.home>

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

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();						\
 	}							\


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-06-12 18:45 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 [this message]
2004-06-12 20:27             ` Alexander Nyberg
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=20040612184511.GD3396@sirius.home \
    --to=vsu@altlinux.ru \
    --cc=alexn@telia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=stian@nixia.no \
    /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