* 2.6.10-rc3, i386: fpu handling on sigreturn
@ 2004-12-22 17:42 Bodo Stroesser
0 siblings, 0 replies; 6+ messages in thread
From: Bodo Stroesser @ 2004-12-22 17:42 UTC (permalink / raw)
To: linux-kernel
Maybe, there is a problem in i386 fpu/signal handling:
On i386, if a signal handler is started, the kernel saves the fpu-state
of the interrupted routine in the sigcontext on the stack. Calling
unlazy_fpu() and setting current->used_math=0, the kernel supplies the
signal-handler with a cleared virtual fpu.
On sigreturn(), the old fpu-state of the interrupted routine is
restored.
If a process never used the fpu, it virtually has a cleared fpu.
If such a process is interrupted by a signal handler, no fpu-context is
saved and sigcontext->fpstate is set to NULL.
Assume, that the signal handler uses the fpu. Then, AFAICS, on sigreturn
current->used_math will be 1. Since sigcontext->fpstate still is NULL,
restore_sigcontext() doesn't call restore_i387(). Thus, no
clear_fpu() is done, current->used_math is not reset.
Now, the interrupted processes fpu no longer is cleared!
I don't know, if this could cause trouble, since I'm not an expert for
i386-fpu. But it seems to be not clean.
Best regards
Bodo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.10-rc3, i386: fpu handling on sigreturn
[not found] <41C9B21F.90802@fujitsu-siemens.com.suse.lists.linux.kernel>
@ 2004-12-22 23:24 ` Andi Kleen
2004-12-22 23:49 ` Bodo Stroesser
0 siblings, 1 reply; 6+ messages in thread
From: Andi Kleen @ 2004-12-22 23:24 UTC (permalink / raw)
To: Bodo Stroesser; +Cc: linux-kernel
Bodo Stroesser <bstroesser@fujitsu-siemens.com> writes:
>
> Now, the interrupted processes fpu no longer is cleared!
I agree it's a bug, although it's probably pretty obscure so people
didn't notice it. The right fix would be to just clear_fpu again
in this case. The problem has been in Linux forever.
Here's an untested patch for i386 and x86-64.
-Andi
diff -u linux-2.6.10rc2-time/arch/i386/kernel/signal.c-o linux-2.6.10rc2-time/arch/i386/kernel/signal.c
--- linux-2.6.10rc2-time/arch/i386/kernel/signal.c-o 2004-11-15 12:34:25.000000000 +0100
+++ linux-2.6.10rc2-time/arch/i386/kernel/signal.c 2004-12-23 00:07:18.000000000 +0100
@@ -190,7 +190,8 @@
if (verify_area(VERIFY_READ, buf, sizeof(*buf)))
goto badframe;
err |= restore_i387(buf);
- }
+ } else if (current->used_math)
+ clear_fpu(current);
}
err |= __get_user(*peax, &sc->eax);
diff -u linux-2.6.10rc2-time/arch/x86_64/kernel/signal.c-o linux-2.6.10rc2-time/arch/x86_64/kernel/signal.c
--- linux-2.6.10rc2-time/arch/x86_64/kernel/signal.c-o 2004-10-19 01:55:08.000000000 +0200
+++ linux-2.6.10rc2-time/arch/x86_64/kernel/signal.c 2004-12-23 00:07:19.000000000 +0100
@@ -125,7 +125,8 @@
if (verify_area(VERIFY_READ, buf, sizeof(*buf)))
goto badframe;
err |= restore_i387(buf);
- }
+ } else if (current->used_math)
+ clear_fpu(current);
}
err |= __get_user(*prax, &sc->rax);
diff -u linux-2.6.10rc2-time/arch/x86_64/ia32/ia32_signal.c-o linux-2.6.10rc2-time/arch/x86_64/ia32/ia32_signal.c
--- linux-2.6.10rc2-time/arch/x86_64/ia32/ia32_signal.c-o 2004-10-19 01:55:08.000000000 +0200
+++ linux-2.6.10rc2-time/arch/x86_64/ia32/ia32_signal.c 2004-12-23 00:07:17.000000000 +0100
@@ -261,7 +261,8 @@
if (verify_area(VERIFY_READ, buf, sizeof(*buf)))
goto badframe;
err |= restore_i387_ia32(current, buf, 0);
- }
+ } else if (current->used_math)
+ clear_fpu(current);
}
{
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.10-rc3, i386: fpu handling on sigreturn
2004-12-22 23:24 ` 2.6.10-rc3, i386: fpu handling on sigreturn Andi Kleen
@ 2004-12-22 23:49 ` Bodo Stroesser
2004-12-22 23:54 ` Andi Kleen
0 siblings, 1 reply; 6+ messages in thread
From: Bodo Stroesser @ 2004-12-22 23:49 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Andi Kleen wrote:
> Bodo Stroesser <bstroesser@fujitsu-siemens.com> writes:
>
>>Now, the interrupted processes fpu no longer is cleared!
>
>
> I agree it's a bug, although it's probably pretty obscure so people
> didn't notice it. The right fix would be to just clear_fpu again
> in this case. The problem has been in Linux forever.
Wouldn't it be better to also reset used_math to 0? (As it has been,
before the sighandler was started)
Bodo
>
> Here's an untested patch for i386 and x86-64.
>
> -Andi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.10-rc3, i386: fpu handling on sigreturn
2004-12-22 23:49 ` Bodo Stroesser
@ 2004-12-22 23:54 ` Andi Kleen
2004-12-23 9:33 ` Bodo Stroesser
0 siblings, 1 reply; 6+ messages in thread
From: Andi Kleen @ 2004-12-22 23:54 UTC (permalink / raw)
To: Bodo Stroesser; +Cc: Andi Kleen, linux-kernel
On Thu, Dec 23, 2004 at 12:49:39AM +0100, Bodo Stroesser wrote:
> Andi Kleen wrote:
> >Bodo Stroesser <bstroesser@fujitsu-siemens.com> writes:
> >
> >>Now, the interrupted processes fpu no longer is cleared!
> >
> >
> >I agree it's a bug, although it's probably pretty obscure so people
> >didn't notice it. The right fix would be to just clear_fpu again
> >in this case. The problem has been in Linux forever.
> Wouldn't it be better to also reset used_math to 0? (As it has been,
> before the sighandler was started)
It would only be an optimization, and i doubt it's worth to optimize for
such an obscure case.
-Andi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.10-rc3, i386: fpu handling on sigreturn
2004-12-22 23:54 ` Andi Kleen
@ 2004-12-23 9:33 ` Bodo Stroesser
2004-12-23 11:29 ` Andi Kleen
0 siblings, 1 reply; 6+ messages in thread
From: Bodo Stroesser @ 2004-12-23 9:33 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Andi Kleen wrote:
> On Thu, Dec 23, 2004 at 12:49:39AM +0100, Bodo Stroesser wrote:
>
>>Andi Kleen wrote:
>>
>>>Bodo Stroesser <bstroesser@fujitsu-siemens.com> writes:
>>>
>>>
>>>>Now, the interrupted processes fpu no longer is cleared!
>>>
>>>
>>>I agree it's a bug, although it's probably pretty obscure so people
>>>didn't notice it. The right fix would be to just clear_fpu again
>>>in this case. The problem has been in Linux forever.
>>
>>Wouldn't it be better to also reset used_math to 0? (As it has been,
>>before the sighandler was started)
>
>
> It would only be an optimization, and i doubt it's worth to optimize for
> such an obscure case.
>
> -Andi
Sorry, I don't agree. AFAICS, if used_math isn't reset, on the next
attempt of the process to use the fpu, it will be reloaded with the
values, that come from the sighandler and that still reside in
thread.i387. Thus, clear_cpu() without resetting used_math has no
effect to the userspace task.
Resetting current->used_math to 0 would make math_state_restore()
calling init_fpu(), that clears thread.i387 before the fpu is loaded.
Bodo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.10-rc3, i386: fpu handling on sigreturn
2004-12-23 9:33 ` Bodo Stroesser
@ 2004-12-23 11:29 ` Andi Kleen
0 siblings, 0 replies; 6+ messages in thread
From: Andi Kleen @ 2004-12-23 11:29 UTC (permalink / raw)
To: Bodo Stroesser; +Cc: Andi Kleen, linux-kernel
> Sorry, I don't agree. AFAICS, if used_math isn't reset, on the next
> attempt of the process to use the fpu, it will be reloaded with the
> values, that come from the sighandler and that still reside in
> thread.i387. Thus, clear_cpu() without resetting used_math has no
> effect to the userspace task.
> Resetting current->used_math to 0 would make math_state_restore()
> calling init_fpu(), that clears thread.i387 before the fpu is loaded.
Ok I agree. I revised the patch here.
-Andi
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-12-23 11:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <41C9B21F.90802@fujitsu-siemens.com.suse.lists.linux.kernel>
2004-12-22 23:24 ` 2.6.10-rc3, i386: fpu handling on sigreturn Andi Kleen
2004-12-22 23:49 ` Bodo Stroesser
2004-12-22 23:54 ` Andi Kleen
2004-12-23 9:33 ` Bodo Stroesser
2004-12-23 11:29 ` Andi Kleen
2004-12-22 17:42 Bodo Stroesser
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox