| History log of /src/tests/kernel/t_signal_and_sp.c |
| Revision | | Date | Author | Comments |
| 1.21 |
| 26-Apr-2025 |
uwe | t_signal_and_sp: sh3 - mark expected failures
misaligned_sp_and_signal and signalsp_sigaltstack currently fail on
sh3 b/c the stack is not force-aligned for signal handlers. Make
signalsphandler more robust by not touching the stack - we can save
r12 (GOT) in a register.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.20 |
| 26-Apr-2025 |
riastradh | t_signal_and_sp: Define __EXPOSE_STACK to get STACK_ALIGNBYTES.
This is a bit silly: sys/param.h unconditionally defines
STACK_ALIGNBYTES if machine/param.h does, but if machine/param.h
doesn't, then it only provides the default
#define STACK_ALIGNBYTES __ALIGNBYTES
under the condition that __EXPOSE_STACK is defined.
But using __EXPOSE_STACK here is a lower-risk change than touching
sys/param.h.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.19 |
| 26-Apr-2025 |
riastradh | t_signal_and_sp: Get STACK_ALIGNBYTES from sys/param.h.
Fills in a default of __ALIGNBYTES if machine/param.h doesn't define
it.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.18 |
| 25-Apr-2025 |
riastradh | hppa _lwp_makecontext: Align stack pointer.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.17 |
| 25-Apr-2025 |
riastradh | mips _lwp_makecontext: Align sp.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.16 |
| 25-Apr-2025 |
riastradh | alpha: Align signal pointer on entry to signal handler.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.15 |
| 25-Apr-2025 |
riastradh | mips: Align stack pointer on entry to signal handler.
Based on a patch by rin@. The variant approach I took puts the stack
frame allocation and alignment logic in one place (getframe, used by
sendsig_siginfo for native (n64, on mips), netbsd32_sendsig_siginfo
for compat32 (n32/o32, on mips), and sendsig_sigcontext (compat 1.6))
and reduces the chance of provoking compiler exploitation of
undefined behaviour by doing arithmetic in uintptr_t rather than in
pointers to large aligned structs. This also ensures the resulting
pointer is aligned for the object (struct siginfo_sigframe, struct
siginfo_sigframe32, struct sigcontext), not just for the ABI stack
alignment.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.14 |
| 25-Apr-2025 |
riastradh | t_signal_and_sp: Check alignment of default thread stack too.
Not just with pthread_attr_setstack.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.13 |
| 24-Apr-2025 |
riastradh | x86: Make sure esp is aligned when delivering signal.
While here, use STACK_ALIGNBYTES consistently for the alignment mask
(or STACK_ALIGNBYTES32 in amd64 for the compat32 alignment mask).
PR kern/59327: user stack pointer is not aligned properly
|
| 1.12 |
| 24-Apr-2025 |
riastradh | t_signal_and_sp: contextsplink test may not be broken on n64.
n32 and n64 have the same stack alignment requirement (16-byte), so
if there were a problem it would probably manifest on n32 too. But
the only things that __resumecontext does with a misaligned sp are:
1. syscall getcontext (not even via the syscall stub, but via the
syscall instruction directly), which is unlikely to care; and
2. tail-call setcontext, which does a syscall (again, unlikely to
care) that will discard the caller's sp and replace it altogether.
So I'm not sure we can even test potential adverse consequences of
misalignment inside __resumecontext, short of interposing our own
setcontext symbol to artificially verify its stack alignment before
passing on to the syscall -- which, while feasible, is maybe not
worth the effort.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.11 |
| 24-Apr-2025 |
riastradh | t_signal_and_sp: Mark signalsp xfail on mips n32/n64.
The kernel takes an initially aligned stack pointer and subtracts
sizeof(struct sigframe_siginfo) or sizeof(struct sigframe_siginfo32)
from it -- that is, 872=0x368 or 792=0x318 bytes, respectively. But
n32 and n64 require 16-byte stack alignment.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.10 |
| 21-Apr-2025 |
riastradh | t_signal_and_sp: Fix threadsp test to actually test the thread sp.
Copypasta error had it testing alignment of signalsp instead, and
since it was always null, that always passed. Mark it xfail on mips
now as originally expected.
While here, deal with some other issues:
- Test was failing on riscv for me because I haven't updated this
`current' VM in a while so it didn't have the fix for 57721
(pthread_attr_setstack incorrectly adjusts address as if for guard
page). Don't mark it xfail.
- Fix amd64 threadspfunc.S to adjust rsp like in all the other amd64
stubs so it's congruent to 0 mod 16, not congruent to 8 mod 16.
- Fix hppa contextspfunc.S to use separate registers for separate
purposes at the same time, instead of expecting addil to preserve
%r1 AND yield a result we use later in %r1.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.9 |
| 21-Apr-2025 |
riastradh | t_signal_and_sp: Test makecontext with uc_link too.
This exercises the resumecontext path, which currently leaves the
stack pointer misaligned on mipsn64 (note: not mips64, which is
64-bit mips with n32 ABI).
Also add some assertions about the stack pointer lying within the
expected stack range and mark riscv inexplicably broken for the
pthread_create sp. And mark the hppa context/thread tests broken --
not yet sure what's wrong with them.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.8 |
| 21-Apr-2025 |
riastradh | t_signal_and_sp: Fix threadspfunc on mips.
1. Writing branch delay slots requires `.set noreorder'. Got used to
reading and writing RISCy code with branch delay slots ages ago,
still haven't gotten used to having to tell the assembler `no, I
really want you to assemble the instructions I wrote, as I wrote
them, and not some other instructions in some other order'.
2. Return value is v0 on mips, not a0 like modern mips^W^Wriscv.
With this, the threadsp test passes on mips.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.7 |
| 21-Apr-2025 |
riastradh | t_signal_and_sp: Test makecontext and pthread_create stack alignment.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.6 |
| 20-Apr-2025 |
riastradh | t_signal_and_sp: Add i386 support.
i386 too is confused by misaligned sigaltstack or esp on interrupt.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.5 |
| 20-Apr-2025 |
riastradh | t_signal_and_sp: Add mips support.
PR kern/59327: user stack pointer is not aligned properly
PR kern/58149: Cannot return from a signal handler if SP was
misaligned when the signal arrived
Stack pointer misaligment in some cases hypothesized to be a possible
cause of:
PR port-evbmips/59236: Multiple segfaults in erlite3 boot
|
| 1.4 |
| 20-Apr-2025 |
riastradh | t_signal_and_sp: Add alpha support.
Turns out alpha too gets confused by by misaligned sigaltstack, and
by misaligned sp in the interrupted code, when a signal is delivered.
PR kern/59327: user stack pointer is not aligned properly
PR kern/58149: Cannot return from a signal handler if SP was
misaligned when the signal arrived
|
| 1.3 |
| 20-Apr-2025 |
riastradh | t_signal_and_sp: Check sp on elf constructor/destructor entry too.
XXX Should maybe test both .ctors/.dtors and .init/fini_array, but
for now I'm limiting this to whatever gcc uses by default for each
architecture.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.2 |
| 20-Apr-2025 |
riastradh | Test stack pointer alignment in various scenarios.
1. elf entry point
2. main function
3. signal handler
Extend the test to amd64 while here -- fortunately both aarch64 and
amd64 pass, but others, such as mips, will fail:
PR kern/59327: user stack pointer is not aligned properly
This extends the test that was previously written for:
PR kern/58149: aarch64: Cannot return from a signal handler if SP was
misaligned when the signal arrived
With any luck, this will help us to systematically eradicate misaligned
stack pointers as hypothesized to be the reason for:
PR port-mips/59236: Multiple segfaults in erlite3 boot
|
| 1.1 |
| 22-Apr-2024 |
pho | Add a test for kern/58149
aarch64: Cannot return from a signal handler if SP was misaligned when the signal arrived
|
