Re: signal delivery, was Re: reliable reproducer

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 enough. 
I thought the exception frame had remained on the kernel stack to be 
restored, but I'd missed that it is actually being restored from the 
user stack copy to the kernel stack.

Need to go back and check whether the sigmask (located after uc_filler 
in rt sigframes) ever got clobbered.

>>> Wouldn't that depend on the exception frame format? Perhaps it is
>>> unsafe to treat any format 0xB exception frame in the way we do. If
>>> so, what do we do about address error exceptions, which are to produce
>>> SIGBUS? The Programmers Reference Manual says "a long bus fault stack
>>> frame may be generated" in this case.
>>
>> We don't handle access errors (beyond terminating the offending

Meant to say 'address errors' there. These are misaligned instruction 
accesses only, and we take them to indicate corruption of the binary or 
stack, so abort the process.

>> process).
>>
>
> SIGBUS could be caught and handled, perhaps followed by a setcontext() or
> siglongjmp() rather than return. So I don't think we get to disallow frame
> format 0xB.

Yes, we may still need to take these signals. But we don't have to 
deliver the signals to the user process while exception processing is 
still in progress. For bus faults mid-instruction, it isn't enough to 
map in a page so writes can succeed, we also need to resume the 
instruction to carry out the write.

Come to think of it, the same argument applies for faults taken at an 
instruction boundary. These need to be resumed as well, they just take 
less information to load back into the processor.

Now I just wonder why 040 bus errors (exception restart instead of 
resume) aren't a problem. Pending writebacks are handled during signal 
return there, too. But the format 7 frame is only 15 longwords, the 
format b one is 23 longwords. We know increasing the apparent length of 
the signal frame helps ...

Anyway, Andreas' patch addresses the issue without incurring too much 
delay in signal processing. If we find out what causes corruption of the 
exception frame, Andreas' patch can be dropped once a fix is in place.

Cheers,

	Michael