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.
