SIGSTKSZ/MINSIGSTKSZ too small on 64bit

[Ryan Arnold]

Alan Modra <amodra at gmail.com> wrote on 07/26/2013 12:05:28 AM:

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

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.

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.

Ryan S. Arnold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20130726/3a5ff55e/attachment.html>