From: "Kevin D. Kissell" <kevink@mips.com>
To: "Daniel Jacobowitz" <dan@debian.org>,
"Carsten Langgaard" <carstenl@mips.com>
Cc: <linux-mips@oss.sgi.com>
Subject: Re: FP emulator patch
Date: Thu, 16 Aug 2001 02:05:39 +0200 [thread overview]
Message-ID: <010001c125e7$35ca2d80$0deca8c0@Ulysses> (raw)
In-Reply-To: 20010815110634.A19305@nevyn.them.org
> Two comments, especially since parts of this seem to be the patch I
> posted here over a month ago.
>
> > Index: linux/arch/mips/kernel/signal.c
>
> > @@ -353,12 +355,11 @@
> > owned_fp = (current == last_task_used_math);
> > err |= __put_user(owned_fp, &sc->sc_ownedfp);
> >
> > - if (current->used_math) { /* fp is active. */
> > + if (owned_fp) { /* fp is active. */
> > set_cp0_status(ST0_CU1);
> > err |= save_fp_context(sc);
> > last_task_used_math = NULL;
> > regs->cp0_status &= ~ST0_CU1;
> > - current->used_math = 0;
> > }
> >
> > return err;
>
> This is absolutely not right. It's righter than the status quo. If we
> don't own the FP, you don't save the FP. Then we can use FP in the
> signal handler, corrupting the process's original floating point
> context.
I only worked on the FP branch emulation fix, and hadn't looked
at the stack signal context problem until now. If the current thread
has any FPU state, it needs to be saved ahead of signal delivery
for the reasons you suggest above. I assume that's the reason
for the previous "if (current->used_math)" condition. If there's
been a problem with FP register corruption in the face of signals
and context switches, it's presumably because, while we're
saving the state in the sigcontext so that it will be restored
on the signal return, we're also clearing last_task_used_math
and curren->used_math. The former means that if
we invoke the signal handler, it returns, and we will restore the
FP context to the register file. But if the signal handler
*doesn't* do any FP, we've got a "dirty" FPU and no owner
for the state, and Bad Things happen. And the way the current
code is written, if the signal handler does happen to acquire
the FPU, the thread inherits the enable, the register contents,
and an obligation to save the FPU state uselessly on the next
context switch.
I don't understand why there is any manipulation of the
FPU ownership status going on in setup_sigcontext(), nor
any persistent modification of the Cp0.Status state.
Shouldn't the code in setup_sigcontext() look more like:
if(owned_fp) {
/* Not clear to me how we could have owned_fp
true with CU1 off. Double check this... */
someaccursednewtemp = regs->cp0_status;
set_cp0_status(ST0_CU1);
err |= save_fp_context(sc);
regs->cp0_status = someaccursednewtemp;
}
Then, in the symmetric code fragment in restore_sigcontext()
if(owned_fp) {
err |= restore_fp_context(sc);
} else {
if (current == last_task_used_math) {
/* signal handler acquired FPU - give it back */
last_task_used_math = NULL;
current->used_math = 0;
clear_cp0_status(ST0_CU1);
}
}
Disclaimer: The above was typed into Outlook Express
and may contain typos, but I think it expresses the idea
well enough for someone to tell me if I'm completely off
base.
Regards,
Kevin K.
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Daniel Jacobowitz <dan@debian.org>,
Carsten Langgaard <carstenl@mips.com>
Cc: linux-mips@oss.sgi.com
Subject: Re: FP emulator patch
Date: Thu, 16 Aug 2001 02:05:39 +0200 [thread overview]
Message-ID: <010001c125e7$35ca2d80$0deca8c0@Ulysses> (raw)
Message-ID: <20010816000539.zGc7kz1wbpgOCgM4_rAHkYpLkBs-UFip6ualQtKus4Y@z> (raw)
In-Reply-To: 20010815110634.A19305@nevyn.them.org
> Two comments, especially since parts of this seem to be the patch I
> posted here over a month ago.
>
> > Index: linux/arch/mips/kernel/signal.c
>
> > @@ -353,12 +355,11 @@
> > owned_fp = (current == last_task_used_math);
> > err |= __put_user(owned_fp, &sc->sc_ownedfp);
> >
> > - if (current->used_math) { /* fp is active. */
> > + if (owned_fp) { /* fp is active. */
> > set_cp0_status(ST0_CU1);
> > err |= save_fp_context(sc);
> > last_task_used_math = NULL;
> > regs->cp0_status &= ~ST0_CU1;
> > - current->used_math = 0;
> > }
> >
> > return err;
>
> This is absolutely not right. It's righter than the status quo. If we
> don't own the FP, you don't save the FP. Then we can use FP in the
> signal handler, corrupting the process's original floating point
> context.
I only worked on the FP branch emulation fix, and hadn't looked
at the stack signal context problem until now. If the current thread
has any FPU state, it needs to be saved ahead of signal delivery
for the reasons you suggest above. I assume that's the reason
for the previous "if (current->used_math)" condition. If there's
been a problem with FP register corruption in the face of signals
and context switches, it's presumably because, while we're
saving the state in the sigcontext so that it will be restored
on the signal return, we're also clearing last_task_used_math
and curren->used_math. The former means that if
we invoke the signal handler, it returns, and we will restore the
FP context to the register file. But if the signal handler
*doesn't* do any FP, we've got a "dirty" FPU and no owner
for the state, and Bad Things happen. And the way the current
code is written, if the signal handler does happen to acquire
the FPU, the thread inherits the enable, the register contents,
and an obligation to save the FPU state uselessly on the next
context switch.
I don't understand why there is any manipulation of the
FPU ownership status going on in setup_sigcontext(), nor
any persistent modification of the Cp0.Status state.
Shouldn't the code in setup_sigcontext() look more like:
if(owned_fp) {
/* Not clear to me how we could have owned_fp
true with CU1 off. Double check this... */
someaccursednewtemp = regs->cp0_status;
set_cp0_status(ST0_CU1);
err |= save_fp_context(sc);
regs->cp0_status = someaccursednewtemp;
}
Then, in the symmetric code fragment in restore_sigcontext()
if(owned_fp) {
err |= restore_fp_context(sc);
} else {
if (current == last_task_used_math) {
/* signal handler acquired FPU - give it back */
last_task_used_math = NULL;
current->used_math = 0;
clear_cp0_status(ST0_CU1);
}
}
Disclaimer: The above was typed into Outlook Express
and may contain typos, but I think it expresses the idea
well enough for someone to tell me if I'm completely off
base.
Regards,
Kevin K.
next prev parent reply other threads:[~2001-08-16 0:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-15 12:53 FP emulator patch Carsten Langgaard
2001-08-15 18:06 ` Daniel Jacobowitz
2001-08-16 0:05 ` Kevin D. Kissell [this message]
2001-08-16 0:05 ` Kevin D. Kissell
2001-08-16 4:20 ` Atsushi Nemoto
2001-08-16 12:35 ` Kevin D. Kissell
2001-08-16 12:35 ` Kevin D. Kissell
2001-08-16 7:07 ` Carsten Langgaard
2001-08-16 4:35 ` Atsushi Nemoto
-- strict thread matches above, loose matches on Subject: below --
2001-08-16 18:23 Kevin D. Kissell
2001-08-16 18:23 ` Kevin D. Kissell
2001-08-16 18:49 ` Pete Popov
2001-08-16 18:53 ` Daniel Jacobowitz
2001-08-16 19:15 ` Jun Sun
2001-08-16 20:40 ` Kevin D. Kissell
2001-08-16 20:40 ` Kevin D. Kissell
2001-08-16 21:34 ` Jun Sun
2001-08-16 22:33 ` Kevin D. Kissell
2001-08-16 22:33 ` Kevin D. Kissell
2001-08-16 22:38 ` Pete Popov
2001-08-16 22:37 ` Daniel Jacobowitz
2001-08-16 23:12 ` Jun Sun
2001-08-16 23:38 ` Kevin D. Kissell
2001-08-16 23:38 ` Kevin D. Kissell
2001-08-16 19:20 ` Kevin D. Kissell
2001-08-16 19:20 ` Kevin D. Kissell
2001-08-16 20:20 ` Jun Sun
2001-08-16 22:58 Kevin D. Kissell
2001-08-16 22:58 ` Kevin D. Kissell
2001-08-16 23:14 ` Jun Sun
2001-08-16 23:46 ` Kevin D. Kissell
2001-08-16 23:46 ` Kevin D. Kissell
2002-09-10 11:55 Carsten Langgaard
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='010001c125e7$35ca2d80$0deca8c0@Ulysses' \
--to=kevink@mips.com \
--cc=carstenl@mips.com \
--cc=dan@debian.org \
--cc=linux-mips@oss.sgi.com \
/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