From: Michael Schmitz <schmitzmic@gmail.com>
To: Brad Boyer <flar@allandria.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
geert@linux-m68k.org, linux-arch@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, torvalds@linux-foundation.org
Subject: Re: [PATCH v4 0/3] m68k: Improved switch stack handling
Date: Mon, 26 Jul 2021 14:00:01 +1200 [thread overview]
Message-ID: <be3ddf9a-745e-4798-17a7-a9d0ddd7eef7@gmail.com> (raw)
In-Reply-To: <20210725101253.GA6096@allandria.com>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
Thanks Brad, Andreas,
I won't rely on ARAnyM for these tests any longer then.
I would be much obliged if one of the m68k kernel crowd with access to a
68040 could apply the two attached patches, on top of Eric's
'refactoring exit' series for preference, and check that any program
attempting a simple sin() or exp() operation exits with SEGV.
If you know of a way to trace said program and set a breakpoint in
do_exit(), please also try to inspect saved registers at that point
(though I'm not sure how to create a dump of the actual registers from
inside the exception handler to compare with).
Cheers,
Michael
On 25/07/21 10:12 pm, Brad Boyer wrote:
> On Sun, Jul 25, 2021 at 07:44:11PM +1200, Michael Schmitz wrote:
>> Am 25.07.2021 um 00:05 schrieb Andreas Schwab:
>>> On Jul 24 2021, Michael Schmitz wrote:
>>>
>>>> According to my understanding, you can't get a F-line exception on
>>>> 68040.
>>> The F-line exception vector is used for all FPU illegal and
>>> unimplemented insns.
>> Thanks - now from my reading of the fpsp040 code (which has mislead me in
>> the past), it would seem that operations like sin() and exp() ought to raise
>> that exception then. I don't see that in ARAnyM.
> Yes, according to the 68040 user's manual, unimplemented and illegal F-line
> instructions trigger the standard F-line exception vector (11) but have
> separate stack frame formats so the fpsp040 code gets some extra data.
> The CPU does a bunch of the prep work so that part doesn't need to be
> emulated in software.
>
> The ARAnyM docs appear to claim a strange combination that wouldn't
> exist in hardware by implementing a full 68882 instead of the limited
> subset found on a real 68040. Strangely, that might have been easier to
> implement. However, it would also completely bypass any use of fpsp040.
>
> Brad Boyer
> flar@allandria.com
>
[-- Attachment #2: 0002-m68k-fpsp040-test-changes-to-copyin-out-exception-ha.patch --]
[-- Type: text/x-patch, Size: 1120 bytes --]
From 3df3164dd0f34f3ef7cfaccd079e83a7d146ee5f Mon Sep 17 00:00:00 2001
From: Michael Schmitz <schmitzmic@gmail.com>
Date: Sat, 24 Jul 2021 15:22:58 +1200
Subject: [PATCH 2/2] m68k/fpsp040 - test changes to copyin/out exception
handling
Call the exception handler in fpsp040/skeleton.S on each f-line
trap. This ought to allow verifying that the added stack frame
is accessible and contains useful data by just tracing a simple
program using one of the floating point operations not supported
by the 68040 FPU.
Signed-off-By: Michael Schmitz <schmitzmic@gmail.com>
---
arch/m68k/fpsp040/skeleton.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/fpsp040/skeleton.S b/arch/m68k/fpsp040/skeleton.S
index 1cbc52b..1ca04bd 100644
--- a/arch/m68k/fpsp040/skeleton.S
+++ b/arch/m68k/fpsp040/skeleton.S
@@ -302,7 +302,8 @@ real_bsun:
.global real_fline
.global fline
fline:
- jmp fpsp_fline
+ jmp test_fpsp040_die
+ |jmp fpsp_fline
real_fline:
SAVE_ALL_INT
@@ -501,6 +502,7 @@ in_ea:
.section .fixup,#alloc,#execinstr
.even
+test_fpsp040_die:
1:
SAVE_ALL_INT
--
2.7.4
[-- Attachment #3: 0001-m68k-fpsp040-save-full-stack-frame-before-calling-fp.patch --]
[-- Type: text/x-patch, Size: 1647 bytes --]
From 737b74a376f0b3da09ba7cb088e99c2c85b7405c Mon Sep 17 00:00:00 2001
From: Michael Schmitz <schmitzmic@gmail.com>
Date: Sun, 18 Jul 2021 10:31:42 +1200
Subject: [PATCH 1/2] m68k/fpsp040 - save full stack frame before calling
fpsp040_die
The FPSP040 floating point support code does not know how to
handle user space access faults gracefully, and just calls
do_exit(SIGSEGV) indirectly on these faults to abort.
do_exit() may stop if traced, and needs a full stack frame
available to avoid exposing kernel data.
Add the current stack frame before calling do_exit() from the
fpsp040 user access exception handler. Top of stack frame saved
to task->thread.esp0 as is done for system calls.
Unwind the stack frame and return to caller once done, in case
do_exit() is replaced by force_sig() later on. Note that this
will allow the current exception handler to continue with
incorrect state, but the results will never make it to the
calling user program which is terminated by SYSSIGV upon return
from exception.
CC: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
arch/m68k/fpsp040/skeleton.S | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/m68k/fpsp040/skeleton.S b/arch/m68k/fpsp040/skeleton.S
index a8f4161..1cbc52b 100644
--- a/arch/m68k/fpsp040/skeleton.S
+++ b/arch/m68k/fpsp040/skeleton.S
@@ -502,7 +502,14 @@ in_ea:
.section .fixup,#alloc,#execinstr
.even
1:
+
+ SAVE_ALL_INT
+ | save top of frame
+ movel %sp,%curptr@(TASK_THREAD+THREAD_ESP0)
+ SAVE_SWITCH_STACK
jbra fpsp040_die
+ lea 44(%sp),%sp
+ rts
.section __ex_table,#alloc
.align 4
--
2.7.4
next prev parent reply other threads:[~2021-07-26 2:00 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 0:21 [PATCH v4 0/3] m68k: Improved switch stack handling Michael Schmitz
2021-06-23 0:21 ` [PATCH v4 1/3] m68k: save extra registers on more syscall entry points Michael Schmitz
2021-06-23 0:21 ` [PATCH v4 2/3] m68k: correctly handle IO worker stack frame set-up Michael Schmitz
2021-06-23 0:21 ` [PATCH v4 3/3] m68k: track syscalls being traced with shallow user context stack Michael Schmitz
2021-07-25 10:05 ` Geert Uytterhoeven
2021-07-25 20:48 ` Michael Schmitz
2021-07-25 21:00 ` Linus Torvalds
2021-07-26 14:27 ` Greg Ungerer
2021-07-15 13:29 ` [PATCH v4 0/3] m68k: Improved switch stack handling Eric W. Biederman
2021-07-15 23:10 ` Michael Schmitz
2021-07-17 5:38 ` Michael Schmitz
2021-07-17 18:52 ` Eric W. Biederman
2021-07-17 20:09 ` Michael Schmitz
2021-07-17 23:04 ` Michael Schmitz
2021-07-18 10:47 ` Andreas Schwab
2021-07-18 19:47 ` Michael Schmitz
2021-07-18 20:59 ` Brad Boyer
2021-07-19 3:15 ` Michael Schmitz
2021-07-20 20:32 ` Eric W. Biederman
2021-07-20 22:16 ` Michael Schmitz
2021-07-22 14:49 ` Eric W. Biederman
2021-07-23 4:23 ` Michael Schmitz
2021-07-23 22:31 ` Eric W. Biederman
2021-07-23 23:52 ` Michael Schmitz
2021-07-24 12:05 ` Andreas Schwab
2021-07-25 7:44 ` Michael Schmitz
2021-07-25 10:12 ` Brad Boyer
2021-07-26 2:00 ` Michael Schmitz [this message]
2021-07-26 19:36 ` [RFC][PATCH] signal/m68k: Use force_sigsegv(SIGSEGV) in fpsp040_die Eric W. Biederman
2021-07-26 20:13 ` Andreas Schwab
2021-07-26 20:29 ` Eric W. Biederman
2021-07-26 21:25 ` Andreas Schwab
2021-07-26 20:29 ` Michael Schmitz
2021-07-26 21:08 ` [PATCH] " Eric W. Biederman
2021-08-25 15:56 ` Eric W. Biederman
2021-08-26 12:15 ` Geert Uytterhoeven
2021-07-25 11:53 ` [PATCH v4 0/3] m68k: Improved switch stack handling Andreas Schwab
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=be3ddf9a-745e-4798-17a7-a9d0ddd7eef7@gmail.com \
--to=schmitzmic@gmail.com \
--cc=ebiederm@xmission.com \
--cc=flar@allandria.com \
--cc=geert@linux-m68k.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=schwab@linux-m68k.org \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for NNTP newsgroup(s).