Re: [PATCH] nptl: Add tst-minstack-cancel, tst-minstack-exit [BZ #22636]

[Florian Weimer <fweimer at redhat dot com>]

On 01/10/2018 12:53 PM, Adhemerval Zanella wrote:
> On 10/01/2018 08:21, Florian Weimer wrote:
> > I verified that without the guard accounting change in commit
> > 630f4cc3aa019ede55976ea561f1a7af2f068639 (Fix stack guard size
> > accounting) the tst-minstack-cancel test fails on an AVX-512F machine.
> > (tst-minstack-exit still passes.)
> >
> > The two tests cannot be merged because lazy binding in libgcc occurs
> > only once and contributes significantly to stack usage, so the first
> > test would alter stack usage in the second test.
> >
> > 2018-01-10  Florian Weimer  <fweimer@redhat.com>
> >
> > 	[BZ #22636]
> > 	* nptl/Makefile (tests): Add tst-minstack-cancel, tst-minstack-exit.
> > 	* nptl/tst-minstack-cancel.c, nptl/tst-minstack-exit.c: New files.
>
>  From the discussion about PTHREAD_STACK_MIN [1] I think the consensus is
> PTHREAD_STACK_MIN does not include enough stack necessary for the
> cancellation mechanism. Shouldn't we mark 'tst-minstack-cancel.c' as
> an XFAIL?
>
> [1] https://sourceware.org/ml/libc-alpha/2017-12/msg00816.html

I am pretty sure that PTHREAD_STACK_MIN was sufficient for cancellation 
to work on glibc 2.26 (as released) and earlier, across all 
architectures.  The test case pretty much mirrors what ntpd does during 
startup, and it's so widely used that people report problems with that 
pretty quickly.  (It's how this was reported originally.)

I think the XSAVE ld.so trampoline simply introduced a regression, and 
we are putting in changes to fix it (4 KiB of stack added, libgcc_s.so 
with RTLD_NOW).  The new tests try to make sure that it won't happen again.

Thanks,
Florian