RFR: 8225035: Thread stack size issue caused by large TLS size

[Florian Weimer]

* Jiangli Zhou:

> On Thu, Jun 27, 2019 at 12:57 AM Florian Weimer <fweimer at redhat.com> wrote:
>>
>> * Thomas Stüfe:
>>
>> >> I think
>> >>
>> >>   stack_adjust_size += guard_size;
>> >>
>> >> is redundant with the get_minstack-based adjustment because it is either
>> >> included in it directly in the get_minstack value, or indirectly in the
>> >> updated stack size computation in glibc (where it adds the guard size
>> >> internally).
>> >
>> > Please do not change this!
>> >
>> > To me and I guess many others it is very important that nothing at all
>> > changes if this workaround is off.
>>
>> That has already happened because recent glibc adds the guard size to
>> the stack size internally now.
>>
>> But what I meant: only perform the += adjustment above for the
>> !AdjustStackSizeForTLS case.
>
> I'm reluctant to do that, because it adds additional dependencies on
> the glibc implementation. Subtracting the non-TLS size from the value
> returned by __pthread_get_minstack may not be forward compatible in
> the future when __pthread_get_minstack changes. I agree with Thomas to
> keep the workaround as simple as possible.

Even though it is an internal interface, __pthread_get_minstack will not
change its competition.  It will be removed if glibc switches to
allocating the TCB and TLS data off the stack.  But that that point, the
size adjustment for TLS will no loger be necessary.

PTHREAD_MIN_STACK could theoretically change (it is rather small on some
architectures), but we have been extremely reluctant to make that
change, due to dependencies like this one.  Rather, we have made the
effective available stack size larger by other means, for the same value
of PTHREAD_MIN_STACK.  (By not subtracting the guard size, in
particular, and we also avoid calls in to the dynamic loader in more
cases, which tend to require lots of stack space on several
architectures.)

Thanks,
Florian