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
next prev parent 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