Re: signal delivery, was Re: reliable reproducer

Michael Schmitz <[email protected]>
Newsgroups gmane.linux.ports.m68k,gmane.linux.debian.ports.68k
Message-ID <[email protected]>
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 cases except where signal delivery gets in the way,
>>> and it also works if moving the exception frame a little bit further
>>> down the stack. So our treatment of the bus error exception frame
>>> during signal delivery appears to be incorrect. Wouldn't you agree?
>>
>> Inspection of the format b frame placed in the signal frame in both rt
>> and non-rt cases (at the time the signal handler runs) shows the
>> expected contents in the data output buffer, data fault address and ssw.
>> At that time, returning to user space with rte would correctly resume
>> the instruction execution.  I had previously confirmed that the register
>> contents saved in the rt signal frame is correct also.
>>
>> That is with a kernel patched similar to above patch by Finn (using an
>> offset of 128 or 64 instead of 256).
>
> That means things go awry during sys_sigreturn or sys_rt_sigreturn. I'm
> not sure what happens to the exception frame:
>
> 1:
>         | stack contents now:
>         |   [original pt_regs address] [original switch_stack address]
>         |   [unused part of the gap] [moved switch_stack] [moved pt_regs]
>         |   [replacement exception frame]
>         | return value of do_{rt_,}sigreturn() points to moved switch_stack.
>
>         movel   %d0,%sp                         | discard the leftover junk
>         RESTORE_SWITCH_STACK
>         | stack contents now is just [syscall return address] [pt_regs] [frame]
>         | return pt_regs.d0
>         movel   %sp@(PT_OFF_D0+4),%d0
>         rts
>
> ... but I noticed that the sys_rt_sigreturn entry point does
> SAVE_SWITCH_STACK while the sys_sigreturn entry point does not. Yet both
> jump to label 1 above, so both syscalls do RESTORE_SWITCH_STACK. Hmmm.

In my copy of entry.S, sys_sigreturn has SAVE_SWITCH_STACK, just as 
sys_rt_sigreturn does.

Cheers,

	Michael


> .macro SAVE_SWITCH_STACK
>         moveml  %a3-%a6/%d6-%d7,%sp@-
> .endm
>
> .macro RESTORE_SWITCH_STACK
>         moveml  %sp@+,%a3-%a6/%d6-%d7
> .endm
>
> Well, that has to corrupt %a3, right?
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.