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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 10/01/2018 10:47, Florian Weimer wrote:
> On 01/10/2018 01:30 PM, 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).
> 
> Has this text been incorporated anywhere?  It wasn't proposed as a diff, so I didn't comment on it further.
> 
> I firmly believe we shouldn't try to fix regressions by documentation, blaming application authors, especially if there is an alternative which is technically feasible and not too hard to implement and maintain going forward.
> 
> Thanks,
> Florian

I do not think it has been incorporated since Carlos did not gave any update
about it.  However my understanding was that the thread intended exactly to
discuss how to handle PTHREAD_STACK_MIN regarding the various pthread ABI
guarantees and your patch goes contrary to the cancellation discussion back
then.  I just noted that if Carlos documentation ended up being incorporated
on manual (if it is indeed the idea) I think we need to discuss it further. 

> 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.

That's a good point to continue to not guarantee cancellation to work 
with PTHREAD_STACK_MIN regardless. The same scenario might occur in other
architectures as well and we will face the same issue if/when it happens
(binaries that rely on the very trick ntpd uses).