On Wed, Apr 26, 2023 at 09:10:50PM +1200, Michael Schmitz wrote:
> Am 26.04.2023 um 16:42 schrieb Finn Thain:
> >If the long format frame was corrupted while on the user stack, the
> >partially completed MOVEM won't be resumed correctly. That's why I was
> >concerned about a bug in sys_sigreturn.
>
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 g
Hi Finn,
Am 26.04.2023 um 16:42 schrieb Finn Thain:
If the long format frame was corrupted while on the user stack, the
partially completed MOVEM won't be resumed correctly. That's why I was
concerned about a bug in sys_sigreturn.
Yes, it turns out I hadn't read mangle_kernel_stack() carefully
On Apr 26 2023, Michael Schmitz wrote:
> The exception frame is copied to the signal frame for informational
> purposes only
This is not for informational purpose. It is the interrupted context
that is restored by the kernel in the sigreturn syscall.
--
Andreas Schwab, sch...@linux-m68k.org
GP
On Wed, 26 Apr 2023, Michael Schmitz wrote:
> In my copy of entry.S, sys_sigreturn has SAVE_SWITCH_STACK, just as
> sys_rt_sigreturn does.
>
You're right.
I think I've been at this too long.
On Wed, 26 Apr 2023, Michael Schmitz wrote:
> It seems I got confused about user and kernel stack there myself. And
> managed to confuse almost everyone else about this bug. Apologies for
> the incessant noise.
>
Likewise... I think it amuses some readers and annoys others ;-)
> What matters
Hi Finn,
Am 26.04.2023 um 14:02 schrieb Finn Thain:
On Wed, 26 Apr 2023, Michael Schmitz wrote:
Thanks - we had seen evidence that a bus error generated mid-instruction
did leave the USP at the address where the bus fault happened (not
before the instruction started, neither what it would have
Hi Finn,
Am 26.04.2023 um 15:27 schrieb Finn Thain:
On Wed, 26 Apr 2023, Michael Schmitz wrote:
On 26/04/23 07:46, Michael Schmitz wrote:
I had thought the 030 could resume the interrupted instruction using
the information from the exception frame - and that does appear to
work in all other
On Wed, 26 Apr 2023, Michael Schmitz wrote:
> On 26/04/23 07:46, Michael Schmitz wrote:
> >
> > I had thought the 030 could resume the interrupted instruction using
> > the information from the exception frame - and that does appear to
> > work in all other cases except where signal delivery get
On Wed, 26 Apr 2023, Michael Schmitz wrote:
> Thanks - we had seen evidence that a bus error generated mid-instruction
> did leave the USP at the address where the bus fault happened (not
> before the instruction started, neither what it would have been once the
> instruction completed), and th
On Tue, 25 Apr 2023, Andreas Schwab wrote:
> Please try this patch.
Thanks for looking into this. Your patch solves the problem for me and
doesn't seem to cause any regression.
Tested-by: Finn Thain
> Signal delivery should only happen at insn boundaries, but due to the
> way the 030 hand
Hi Andreas,
On 26/04/23 07:46, Michael Schmitz wrote:
Hi Andreas,
On 25/04/23 23:25, Andreas Schwab wrote:
On Apr 25 2023, Finn Thain wrote:
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/signa
Hi Andreas,
On 25/04/23 23:25, Andreas Schwab wrote:
On Apr 25 2023, Finn Thain wrote:
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..9410
Hi Andreas, Finn and Michael,
With no patches installed, I see stack smashing on my IIci after one
boot using a customized 6.2.12 kernel, no initrd, and Debian's SID and
dash. Also, Finn's test program (compiled using gcc 12) generates
illegal instructions, as expected.
With the patch below insta
Please try this patch. Signal delivery should only happen at insn
boundaries, but due to the way the 030 handles return from bus error
exceptions (the insn is resumed, not restarted like on the 040/060) the
kernel may do it in the middle of the faulting insn.
diff --git a/arch/m68k/kernel/entry.S
On Apr 25 2023, Finn Thain wrote:
> 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
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
Hi Finn,
Am 25.04.2023 um 14:32 schrieb Michael Schmitz:
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 excepti
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(si
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 fra
20 matches
Mail list logo
