On 12/7/21 22:47, John David Anglin wrote: > The glibc tst-minsigstksz-5 test fails with a protection id trap. > tst-minsigstksz (pid 19958): Protection id trap (code 7) at 00000000f5b00497 > > The problem seems to be that the signal return trampoline is placed > on the alternate stack but the alternate is not executable. It is > allocated by malloc.> ... > Stacks are normally executable on hppa so the trampoline works. But > user code wouldn't normally make an alternate stack executable. True, I think most people just forget that such architectures exist. Anyway, the glibc testcase is interesting. The pretty similar sigaltstack testcase from LTP does work: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/sigaltstack/sigaltstack01.c Both use malloc() to allocate the memory, the only difference is the size allocated. If you change the glibc testcase to: -- size_t stack_buffer_size = 64 * 1024 * 1024; ++ size_t stack_buffer_size = SIGSTKSZ; it allocates only 8kB instead of 64MB. It seems glibc uses brk() in both cases, but when allocating 64MB it additionally adds a mmap() with READ/WRITE permissions only: brk(0x606000) = 0x606000 mmap2(NULL, 67112960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf303f000 This will then break - as you mentioned - the signal handling on parisc. I see those options to fix it: a) Fix the application to map the memory +x b) Add some code to glibc to map the memory +x when sigaltstack is called. c) Add some (parisc-only) code to kernel to set the permission. I've looked into c), but that's not my favorite choice. Helge