Hi,
On 25.4.2023 4.55, Finn Thain wrote:
On Tue, 25 Apr 2023, Finn Thain wrote:
...
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;
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?
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,
While this is most likely Hatari emulation [1] issue, it has some of the
same triggering conditions, so I thought to mention it...
Above patch does not fix kernel panic I'm seen on booting Linux under
Hatari emulated Atari Falcon, to a small IDE root fs with just (old
Debian) Busybox and a shell script acting as init:
----------------------------------------
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU: 0 PID: 1 Comm: sh Not tainted 6.2.0hatari-00006-g01793428cbc5-dirty #4
Stack from 00819dc8:
00819dc8 0032b646 0032b646 00027800 00000001 00819de8 00292878
0032b646
00819e0c 0028d60e 00027848 0000000b 0081caff 000300d6 00815a90
00000000
00819f2c 00819e50 00028878 003243fd 0000000b 0000000b 00818007
0081ca30
000300d6 0081caf8 00000001 00819f18 0081bbd0 00819f2c 00000000
00000000
00000000 00000000 00819e60 00028ea0 0000000b 0000000b 00819e98
000303c8
0000000b 00818000 00000002 00000000 00000000 00000000 8017705e
00819f78
Call Trace: [<00027800>] set_cpu_online+0x1c/0x3e
[<00292878>] dump_stack+0x10/0x16
[<0028d60e>] panic+0xc4/0x22a
[<00027848>] arch_local_irq_enable+0x0/0x22
[<000300d6>] do_signal_stop+0x0/0x152
[<00028878>] do_exit+0x138/0x642
[<000300d6>] do_signal_stop+0x0/0x152
[<00028ea0>] do_group_exit+0x22/0x62
[<000303c8>] get_signal+0xf8/0x4ba
[<00003508>] test_ti_thread_flag+0x0/0x1a
[<00003f4a>] do_notify_resume+0x36/0x488
[<00005706>] send_fault_sig+0x28/0x8c
[<00005888>] do_page_fault+0x11e/0x242
[<00005814>] do_page_fault+0xaa/0x242
[<00002814>] do_signal_return+0x10/0x1a
[<00020007>] _I_CALL_TOP+0xd83/0x1900
[<0000b280>] sp_over+0x2c/0x3c
[<00007201>] atari_irq_enable+0x3/0x2a
[<000066f6>] atari_get_hardware_list+0x33a/0x3e8
----------------------------------------
(Only way to get rid of the panic is disabling both CPU cache and
prefetch emulation.)
Is it possible that in your case there's also IRQ (exception) happening
at the same time with page fault and signal?
- Eero
[1] 030 MMU vs. cache/prefetch vs. exception handling vs. IDE emulation.
