Re: signal delivery, was Re: reliable reproducer

Finn Thain
2023-04-29T06:09:23Z

On Sat, 29 Apr 2023, Michael Schmitz wrote:

>
> Might be, but this has all been on m68k v6.3-rc7, and I hadn't seen the
> memory squeeze before there. I'll have to run a few hundred of the test
> case on an unpatched v6.3-rc7 and on the one with the minimal frame gap
> to be sure though.
>

You could use a stable kernel for this.

> > Anyway, I agree that stkadj would need to account for the gap, as you
> > pointed out earlier.
>
> Not sure about that anymore - mangle_kernel_stack() does not even use
> stkadj to shift contents on the kernel stack (after restoring the
> exception frame from the signal stack, but it uses the start address of
> the frame for that copy operation, and uses a local buffer to move it
> from user space to kernel space). It uses the extra frame size from the
> exception frame directly.
>
> stkadj is the offset of the replacement exception frame on the kernel
> stack. The replacement frame gets us into the user space signal handler
> instead of completing the exception right away. stkadj is used to skip
> that replacement exception frame used for the signal handler on the
> final rte (after a trip through sys_sigreturn to copy the original
> exception frame back on the kernel stack).
>
> The offset we use for he signal stack on the user stack does not matter
> here at all.
>
> Or so my limited understanding...

Thanks for passing it on. I sure wish this stuff was documented somewhere.

>
> >
> >>> I believe we can use USP to get a worst case estimate for the future
> >>> extent of the user stack. ...
> >>
> >> What is the most data a moveml <...>,sp@- can take? If that's not too
> >> much, a constant offset for the signal stack in case of format b
> >> frames on 020/030 might be easiest.
> >
> > I think it's 64 bytes (16 registers). But we also have to consider all
> > of the other instructions that may write to the stack. There's
> > probably a reason why do_page_fault() picked a 256 byte gap (?)
>
> That's not used as a gap, just to catch any user access below the user
> stack pointer.
>

MOVEM _is_ accessing the stack below the stack pointer. That's why the 256
is relevant here.