<html><body>
<p><tt><font size="2">Alan Modra <amodra@gmail.com> wrote on 07/26/2013 12:05:28 AM:<br>
<br>
> Alan Modra <amodra@gmail.com> </font></tt><br>
<tt><font size="2">> 07/26/2013 12:05 AM</font></tt><br>
<tt><font size="2">> <br>
> To</font></tt><br>
<tt><font size="2">> <br>
> Anton Blanchard <anton@samba.org>, </font></tt><br>
<tt><font size="2">> <br>
> cc</font></tt><br>
<tt><font size="2">> <br>
> Michael Neuling <mikey@neuling.org>, Ryan Arnold/Rochester/<br>
> IBM@IBMUS, linuxppc-dev@lists.ozlabs.org</font></tt><br>
<tt><font size="2">> <br>
> Subject</font></tt><br>
<tt><font size="2">> <br>
> Re: SIGSTKSZ/MINSIGSTKSZ too small on 64bit</font></tt><br>
<tt><font size="2">> <br>
> On Fri, Jul 26, 2013 at 12:23:25PM +1000, Anton Blanchard wrote:<br>
> > <br>
> > Hi,<br>
> > <br>
> > Alan has been looking at a glibc test fail. His analysis shows SEGVs<br>
> > in signal handlers using sigaltstack, and that MINSIGSTKSZ and SIGSTKSZ<br>
> > are too small.<br>
> > <br>
> > We increased the size of rt_sigframe in commit 2b0a576d15e0<br>
> > (powerpc: Add new transactional memory state to the signal context) but<br>
> > didn't bump either SIGSTKSZ and MINSIGSTKSZ. We need to do that in both<br>
> > the kernel and glibc, but I'm a bit worried we could have broken<br>
> > existing applications that use sigaltstack.<br>
> <br>
> Before VSX changes, struct rt_sigframe size was 1920 plus 128 for<br>
> __SIGNAL_FRAMESIZE giving ppc64 exactly the default MINSIGSTKSZ of<br>
> 2048.<br>
> <br>
> After VSX, ucontext increased by 256 bytes. Oops, we're over<br>
> MINSIGSTKSZ. Add another ucontext for TM and rt_sigframe is now at<br>
> 3872, giving actual MINSIGSTKSZ of 4000.<br>
> <br>
> The glibc testcase that I was looking at was tst-cancel21, which<br>
> allocates 2*SIGSTKSZ (not because the test is trying to be<br>
> conservative, but because the test actually has nested signal stack<br>
> frames). We blew the allocation by 48 bytes when using current<br>
> mainline gcc to compile glibc (le ppc64).<br>
> <br>
> The required stack depth in _dl_lookup_symbol_x from the top of the<br>
> next signal frame was 10944 bytes. I guess you'd want to add 288 to<br>
> that, implying an actual SIGSTKSZ of 11232.<br>
> <br>
> I think we want<br>
> #define MINSIGSTKSZ 4096<br>
> #define SIGSTKSZ 16384<br>
> <br>
> frame size r1<br>
> #0 0x00000000295cdaec in _dl_lookup_symbol_x(memset) 190<br>
> #1 0x00000000295d3c4c in _dl_fixup() b0 10003310160<br>
> #2 0x00000000295dc818 in _dl_runtime_resolve() b0 10003310210<br>
> #3 0x00001fffff59ea8c in uw_init_context_1() a30 100033102c0<br>
> #4 0x00001fffff59f560 in libc:_Unwind_ForcedUnwind() c90 10003310cf0<br>
> #5 0x00001ffffffb9538 in pt:_Unwind_ForcedUnwind() 90 10003311980<br>
> #6 0x00001ffffffb6418 in __pthread_unwind() 70 10003311a10<br>
> #7 0x00001ffffffaaeb0 in sigcancel_handler() 70 10003311a80<br>
> #8 <signal handler called> 1ffffffe0448 tramp fa0 10003311af0<br>
> 10003311b70 rt_sigframe<br>
> 10003311c58 sigcontext.gp_regs<br>
> 10003311dd8 sigcontext.fp_regs<br>
> 10003311ee0 sigcontext.v_regs<br>
> 10003311ef0 sigcontext.vmx<br>
> 100033128d8 rt_sigframe.pinfo offset d68<br>
> 10003312968 rt_sigframe.abigap<br>
> 10003312a88 end + 8 alignment<br>
> #9 0x00001ffffffb6f9c in 80 10003312a90<br>
> #10 0x00001ffffffb6f84 in 10003312b10<br>
> #11 0x00000000100020f4 in delete_temp_files() 80 10003312dc0<br>
> #12 0x0000000010002198 in 10003313070<br>
> #13 <signal handler called><br>
> #14 0x00001ffffffb6f9c in ?? ()<br>
> #15 0x00001ffffffb6f84 in ?? ()<br>
> #16 0x0000000010002274 in ?? ()<br>
> #17 0x0000000010002430 in ?? ()<br>
> #18 0x0000000010002644 in ?? ()<br>
> #19 0x0000000010001a1c in ?? ()<br>
> #20 0x00001fffffe17f0c in ?? ()<br>
> #21 0x00001fffffe18134 in ?? ()<br>
> #22 0x0000000000000000 in ?? ()<br>
</font></tt><br>
<tt><font size="2">Adhemerval and I were just looking at the signal stack frames and I'd noticed the increase in size due to the addition of the HTM bits so this is great timing.</font></tt><br>
<br>
<tt><font size="2">I tried a sigstack.h patch that increased the values as you indicated and it cleaned up the failing tst-cancel21* testcases on POWER8. I didn't try it on POWER7 yet.</font></tt><br>
<br>
<tt><font size="2">Ryan S. Arnold</font></tt></body></html>