From: Michael Schmitz <schmitzmic@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: geert@linux-m68k.org, linux-arch@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, torvalds@linux-foundation.org,
schwab@linux-m68k.org
Subject: Re: [PATCH v4 0/3] m68k: Improved switch stack handling
Date: Sun, 18 Jul 2021 08:09:36 +1200 [thread overview]
Message-ID: <e9009e13-cfec-c494-0b3b-f334f75cd1e4@gmail.com> (raw)
In-Reply-To: <8735scvklk.fsf@disp2133>
Hi Eric,
Am 18.07.2021 um 06:52 schrieb Eric W. Biederman:
>> I should have looked more closely at skeleton.S - most FPU exceptions
>> handled there call trap_c the same way as is done for generic traps,
>> i.e. SAVE_ALL_INT before, ret_from_exception after.
>>
>> Instead of adding code to entry.S, much better to add it in
>> skeleton.S. I'll try to come up with a way to test this code path
>> (calling fpsp040_die from the dz exception hander seems much the
>> easiest way) to make sure this doesn't have side effects.
>>
>> Does do_exit() ever return?
>
> No. The function do_exit never returns.
Fine - nothing to worry about as regards restoring the stack pointer
correctly then.
> If it is not too much difficulty I would be in favor of having the code
> do force_sigsegv(SIGSEGV), instead of calling do_exit directly.
That _would_ force a return, right? The exception handling in skeleton.S
won't be set up for that.
> Looking at that code I have not been able to figure out the call paths
> that get into skeleton.S. I am not certain saving all of the registers
> on an the exceptions that reach there make sense. In practice I suspect
The registers are saved only so trap_c has a stack frame to work with.
In that sense, adding a stack frame before calling fpsp040_die is no
different.
> taking an exception is much more expensive than saving the registers so it
> might not make any difference. But this definitely looks like code that
> is performance sensitive.
We're only planning to add a stack frame save before calling out of the
user access exception handler, right? I doubt that will be called very
often.
> My sense when I was reading through skeleton.S was just one or two
> registers were saved before the instruction emulation was called.
skeleton.S only contains the entry points for code to handle FPU
exceptions, from what I've seen (plus the user space access code).
Wherever that exception handling requires calling into the C exception
handler (trap_c), a stack frame is added.
Cheers,
Michael
>
next prev parent reply other threads:[~2021-07-17 20:09 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 [this message]
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
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=e9009e13-cfec-c494-0b3b-f334f75cd1e4@gmail.com \
--to=schmitzmic@gmail.com \
--cc=ebiederm@xmission.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).