Re: signal delivery, was Re: reliable reproducer

[Michael Schmitz <schmitzmic@gmail.com>]

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..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);
> Probably the issue is that a bus error exception should never start
> signal delivery when returning to user space.  On the 030 returning from
> a bus error resumes the execution of the faulting insn (unlike the
> 040/060 which restart it), and the saved USP may have the original value
> from before the insn started (modified registers may not be updated
> until the insn is complete or just before the final bus cycle).  Signal
> delivery should only ever happen at insn boundaries.

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 the operation did not complete normally 
after the bus error (at least the value/address seen in the exception 
frame not stored). Finn had also demonstrated that skipping signal 
delivery on bus errors abolishes the stack corruption.  Your patch 
achieves the same objective in a different way, so I'm sure this will 
work as well.

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?

Cheers,

     Michael