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

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 10/01/18 12:30, Adhemerval Zanella wrote:
> 
> 
>> 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.
> 
> 
>> 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.
> 
> So in this case I think the summary Carlos wrote about "What can 
> a thread do with PTHREAD_STACK_MIN?" should be changed to also
> include cancellation (at least this specific scenario).
> 

hm on a second thought it is probably not reasonable to
guarantee cancellation to work (and signal frame to be
included) on PTHREAD_STACK_MIN, it prevents creation of
tiny thread stacks which may be useful and signal frames
can grow big in the future (e.g. sve on aarch64, although
aarch64 has huge PTHREAD_STACK_MIN so that's fortunately
not an issue right now).

it might make sense to silently keep old binaries working,
but not give documented guarantee (deprecate this use), i
don't have a strong opinion which way this goes.