From: Michael Schmitz <schmitzmic@gmail.com> To: Finn Thain <fthain@linux-m68k.org> Cc: debian-68k@lists.debian.org, linux-m68k@lists.linux-m68k.org Subject: Re: signal delivery, was Re: reliable reproducer Date: Thu, 27 Apr 2023 07:45:13 +1200 [thread overview] Message-ID: <1ac37684-2696-6103-10d9-92914b0497a1@gmail.com> (raw) In-Reply-To: <7c86ad1d-7bbd-8f61-5ac4-56a1b99a8663@gmail.com> Hi Finn, On 25/04/23 14:32, Michael Schmitz wrote: > Hi Finn, > > Am 25.04.2023 um 13:55 schrieb Finn Thain: >> On Tue, 25 Apr 2023, Finn Thain wrote: >> >>> On Tue, 25 Apr 2023, Michael Schmitz wrote: >>> >>>> As to a cause for the corruption: all the calculations in setup_frame >>>> and sys_sigreturn use fsize, but get_sigframe() masks off the result >>>> of usp - sizeof(sigframe) - fsize to place the entire frame at a >>>> quadword boundary. >>> ... >>> >>> I wonder if we are seeing some fallout from the issue described in >>> do_page_fault() i.e. usp is unreliable. >>> >>> /* Accessing the stack below usp is always a bug. The >>> "+ 256" is there due to some instructions doing >>> pre-decrement on the stack and that doesn't show up >>> until later. */ >>> if (address + 256 < rdusp()) >>> goto map_err; >>> Minimal gap that avoids the corruption for me (in your patch below) is 20 bytes. Still can't explain that (and I won't have time to throw more confusion into the discussion until maybe the weekend). Cheers, Michael >>> Maybe we should try modifying get_sigframe() to increase the gap >>> between >>> the signal and exception frames from 0-1 long words up to 64-65 long >>> words. >>> >> >> It turns out that doing so (patch below) does make the problem go away. >> Was the exception frame getting clobbered? > > Might happen, if the frame gap isn't actually equal to the exception > frame extra size anymore? Aligning the start of the signal frame to > the next lower quadword boundary increases the gap size. > > When setting up the sigframe, the extra is copied to the correct > location (right past struct sigframe, or into uc_filler). When moving > that exception frame into place, the assumption is that the gap is the > extra size, not more. > > I'll try dropping the quadword alignment constraint - the return > trampoline still ought to remain longword aligned. > > Cheers, > > Michael > > >> >> diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c >> index b9f6908a31bc..94104699f5a8 100644 >> --- a/arch/m68k/kernel/signal.c >> +++ b/arch/m68k/kernel/signal.c >> @@ -862,7 +862,7 @@ get_sigframe(struct ksignal *ksig, size_t >> frame_size) >> { >> unsigned long usp = sigsp(rdusp(), ksig); >> >> - return (void __user *)((usp - frame_size) & -8UL); >> + return (void __user *)((usp - 256 - frame_size) & -8UL); >> } >> >> static int setup_frame(struct ksignal *ksig, sigset_t *set, >>
next prev parent reply other threads:[~2023-04-26 19:45 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4a9c1d0d-07aa-792e-921f-237d5a30fc44.ref@yahoo.com>
[not found] ` <4a9c1d0d-07aa-792e-921f-237d5a30fc44@yahoo.com>
2023-01-30 10:12 ` stack smashing detected Geert Uytterhoeven
2023-01-31 3:05 ` Michael Schmitz
[not found] ` <af524ac9-f5af-e9fb-e33f-0884a0ebfcb6@yahoo.com>
2023-02-01 18:51 ` Michael Schmitz
2023-02-02 7:52 ` Geert Uytterhoeven
[not found] ` <8fb2aa62-dcec-9bd0-b8da-00d9bb4ddaba@yahoo.com>
2023-02-03 0:15 ` Michael Schmitz
2023-02-05 22:19 ` Michael Schmitz
[not found] ` <33d7ea3e-9bd2-16e4-4d9a-f7aa5657a0f7@yahoo.com>
2023-02-07 22:58 ` Michael Schmitz
2023-02-09 3:41 ` Michael Schmitz
[not found] ` <c01e2f1c-425f-478d-918e-cd1fd37e0008@yahoo.com>
[not found] ` <aee359a6-b5e0-fbe2-3988-779f8601f106@gmail.com>
[not found] ` <8042d988-6dd9-8170-60e9-cdf19118440f@yahoo.com>
[not found] ` <a8f06e4b-db28-c8f9-5e21-3ea0f3eebacd@linux-m68k.org>
[not found] ` <bb27b393-3d02-f42c-5c7f-c27d4936ece9@linux-m68k.org>
[not found] ` <37da2ca2-dd99-8417-7cae-a88e2e7fc1b6@yahoo.com>
[not found] ` <30a1be59-a1fd-f882-1072-c7db8734b1f1@gmail.com>
[not found] ` <39f79c2d-e803-d7b1-078f-8757ca9b1238@yahoo.com>
[not found] ` <c47abfdc-31c8-e7ed-1c14-90f68710f25d@gmail.com>
[not found] ` <040ad66a-71dd-001b-0446-36cbd6547b37@yahoo.com>
[not found] ` <5b9d64bb-2adc-20a2-f596-f99bf255b5cc@linux-m68k.org>
[not found] ` <56bd9a33-c58a-58e0-3956-e63c61abe5fe@yahoo.com>
[not found] ` <1725f7c1-2084-a404-653d-9e9f8bbe961c@linux-m68k.org>
2023-03-28 3:37 ` core dump analysis, was " Finn Thain
2023-03-31 3:33 ` Finn Thain
2023-04-01 9:27 ` Finn Thain
2023-04-01 10:11 ` Andreas Schwab
2023-04-02 10:46 ` Finn Thain
2023-04-02 22:01 ` Michael Schmitz
2023-04-04 0:13 ` Finn Thain
2023-04-04 23:22 ` Michael Schmitz
2023-04-05 2:00 ` Finn Thain
2023-04-07 1:57 ` Michael Schmitz
2023-04-07 4:03 ` dash behaviour, was Re: core dump analysis Finn Thain
2023-04-07 12:10 ` Geert Uytterhoeven
2023-04-08 5:29 ` Finn Thain
2023-04-09 8:30 ` Geert Uytterhoeven
2023-04-09 3:48 ` Michael Schmitz
2023-04-09 4:42 ` Finn Thain
2023-04-09 4:55 ` Michael Schmitz
2023-04-09 7:32 ` Finn Thain
2023-04-10 8:12 ` Michael Schmitz
2023-04-10 9:39 ` kernel behaviour, was Re: dash behaviour Finn Thain
2023-04-11 4:29 ` Michael Schmitz
2023-04-11 4:50 ` Finn Thain
2023-04-11 7:21 ` Geert Uytterhoeven
2023-04-07 12:06 ` core dump analysis, was Re: stack smashing detected Geert Uytterhoeven
2023-04-09 1:56 ` Michael Schmitz
2023-04-11 0:20 ` instrumentation, was Re: core dump analysis Finn Thain
2023-04-11 4:56 ` Michael Schmitz
2023-04-11 5:54 ` Finn Thain
2023-04-11 7:19 ` Geert Uytterhoeven
2023-04-11 8:24 ` Michael Schmitz
2023-04-12 23:22 ` Eero Tamminen
2023-04-15 15:50 ` Eero Tamminen
2023-04-15 21:56 ` Brad Boyer
2023-04-14 9:30 ` core dump analysis, was Re: stack smashing detected Finn Thain
2023-04-16 1:50 ` Michael Schmitz
2023-04-16 6:44 ` Finn Thain
2023-04-17 23:32 ` Michael Schmitz
2023-04-18 2:04 ` Finn Thain
2023-04-18 5:29 ` Michael Schmitz
2023-04-19 1:50 ` Finn Thain
2023-04-19 8:15 ` Michael Schmitz
2023-04-23 7:46 ` Finn Thain
2023-04-23 21:26 ` Michael Schmitz
2023-04-19 10:50 ` reliable reproducer, was Re: core dump analysis Finn Thain
2023-04-19 11:55 ` Geert Uytterhoeven
2023-04-20 1:02 ` Finn Thain
2023-04-20 0:55 ` Michael Schmitz
2023-04-20 2:57 ` Finn Thain
2023-04-20 4:08 ` Michael Schmitz
2023-04-20 5:17 ` Finn Thain
2023-04-20 5:48 ` Finn Thain
2023-04-20 7:34 ` Michael Schmitz
2023-04-20 7:47 ` Finn Thain
2023-04-20 8:23 ` Michael Schmitz
2023-04-20 8:55 ` Finn Thain
2023-04-20 21:58 ` Michael Schmitz
2023-04-21 1:45 ` Michael Schmitz
2023-04-21 5:52 ` Michael Schmitz
2023-04-21 8:30 ` Finn Thain
2023-04-21 9:18 ` Michael Schmitz
2023-04-22 7:54 ` Michael Schmitz
2023-04-22 8:07 ` Andreas Schwab
2023-04-22 8:16 ` Michael Schmitz
2023-04-22 10:12 ` Andreas Schwab
2023-04-22 18:24 ` Michael Schmitz
2023-04-22 18:38 ` Andreas Schwab
2023-04-22 20:06 ` Michael Schmitz
2023-04-22 20:46 ` Andreas Schwab
2023-04-23 1:41 ` Michael Schmitz
2023-04-23 7:37 ` Andreas Schwab
2023-04-23 8:18 ` Michael Schmitz
2023-04-23 8:23 ` Andreas Schwab
2023-04-23 20:19 ` Michael Schmitz
2023-04-23 21:48 ` Andreas Schwab
2023-04-24 3:51 ` Michael Schmitz
2023-04-24 5:46 ` Michael Schmitz
2023-04-23 9:23 ` Finn Thain
2023-04-23 20:43 ` Michael Schmitz
2023-04-24 23:44 ` Finn Thain
[not found] ` <1d9955d2-6016-a238-142a-887f95465dd8@linux-m68k.org>
[not found] ` <4763c8e2-6fb3-eda6-10d0-94ed1d01cd60@gmail.com>
[not found] ` <a5d70bac-bd00-7131-9ca0-18976f539adf@linux-m68k.org>
[not found] ` <b150c146-cade-bcd3-9c34-d99284dcd153@gmail.com>
[not found] ` <c3d2d874-e366-1d3b-71b0-7a089d40308a@linux-m68k.org>
2023-04-25 1:55 ` signal delivery, was Re: reliable reproducer Finn Thain
2023-04-25 2:32 ` Michael Schmitz
2023-04-25 5:59 ` Michael Schmitz
2023-04-26 19:45 ` Michael Schmitz [this message]
[not found] ` <1c4fc19f-ad9b-7b8f-6638-8b026fe1280b@linux-m68k.org>
[not found] ` <5ac55169-4916-d671-489f-7eb8fb85d336@gmail.com>
[not found] ` <9544ef26-a444-e186-fb1e-0e914acd36af@gmail.com>
[not found] ` <20de24b3-098d-4603-2768-b0468a4fe772@gmail.com>
[not found] ` <69565abb-1cd6-716e-046e-5a6d69a4e617@linux-m68k.org>
[not found] ` <89cb2211-5f6e-07a2-3149-1ad1ad887265@linux-m68k.org>
[not found] ` <d3d27369-8532-ba69-2463-66b8decbee67@gmail.com>
[not found] ` <4b4eacf2-6934-5563-fb47-04843a77a35c@gmail.com>
2023-04-29 0:28 ` Finn Thain
2023-04-29 0:53 ` Finn Thain
2023-04-29 2:53 ` Michael Schmitz
2023-04-29 5:03 ` Finn Thain
2023-04-29 6:01 ` Michael Schmitz
2023-04-29 6:13 ` Finn Thain
2023-04-29 6:43 ` Michael Schmitz
2023-04-29 6:05 ` Finn Thain
2023-04-29 7:11 ` Andreas Schwab
2023-04-29 7:37 ` Michael Schmitz
2023-04-25 9:26 ` Eero Tamminen
2023-04-25 11:25 ` Andreas Schwab
2023-04-25 19:46 ` Michael Schmitz
2023-04-26 1:54 ` Michael Schmitz
2023-04-26 3:27 ` Finn Thain
2023-04-26 3:56 ` Michael Schmitz
2023-04-26 4:53 ` Finn Thain
2023-04-26 2:02 ` Finn Thain
2023-04-26 4:00 ` Michael Schmitz
2023-04-26 4:42 ` Finn Thain
2023-04-26 9:10 ` Michael Schmitz
2023-04-26 21:48 ` Brad Boyer
2023-04-26 8:31 ` Andreas Schwab
2023-04-25 11:53 ` Andreas Schwab
2023-04-26 1:59 ` Finn Thain
2023-04-25 5:18 ` reliable reproducer, was Re: core dump analysis Michael Schmitz
2023-04-22 9:00 ` Michael Schmitz
2023-04-21 1:15 ` Finn Thain
2023-04-21 1:57 ` Michael Schmitz
2023-04-21 1:39 ` Finn Thain
2023-04-20 6:04 ` Finn Thain
2023-04-20 7:40 ` Michael Schmitz
2023-04-20 7:58 ` Finn Thain
2023-04-02 4:09 ` core dump analysis, was Re: stack smashing detected Michael Schmitz
2023-04-02 9:31 ` Finn Thain
2023-04-03 8:26 ` Michael Schmitz
2023-04-04 4:05 ` Finn Thain
2023-04-04 11:05 ` Finn Thain
2023-04-09 4:02 ` Finn Thain
2023-02-03 23:39 ` Finn Thain
[not found] ` <86badf6e-2cc8-1937-1a2f-45334bb338f4@yahoo.com>
2023-02-05 22:29 ` Debian initramfs/initrd, was " Finn Thain
2023-02-05 23:18 ` John Paul Adrian Glaubitz
[not found] ` <8107e04f-fd60-c6e3-2bad-cc0d99877967@yahoo.com>
2023-02-06 7:52 ` Geert Uytterhoeven
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=1ac37684-2696-6103-10d9-92914b0497a1@gmail.com \
--to=schmitzmic@gmail.com \
--cc=debian-68k@lists.debian.org \
--cc=fthain@linux-m68k.org \
--cc=linux-m68k@lists.linux-m68k.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