This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 10/01/18 11:53, 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
> 

existing code relies on it:
https://sourceware.org/ml/libc-help/2017-02/msg00000.html

tl;dr: glibc uses dlopen for cancellation which can fail, so
the only way for ntpd to avoid crashing at runtime or leaking
blocked threads is to a cancel a thread at program startup time
(which does the dlopen early) and it uses a minimal stack to
avoid wasting resources for this nasty workaround.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]