Re: [PATCH] Fix nptl/tst-cond1{6,7} on 32-bit with many cpus

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Mon, Mar 26, 2012 at 5:34 PM, David Miller <davem@davemloft.net> wrote:
> From: "Carlos O'Donell" <carlos@systemhalted.org>
> Date: Mon, 26 Mar 2012 10:44:21 -0400
>> On Sun, Mar 25, 2012 at 9:47 PM, David Miller <davem@davemloft.net> wrote:
>>> @@ -76,9 +76,15 @@ do_test (void)
>>> ? count *= 4;
>>>
>>> ? pthread_t th[count];
>>> - ?int i, ret;
>>> + ?pthread_attr_t attr;
>>> + ?int i, ret, sz;
>>> + ?pthread_attr_init (&attr);
>>> + ?sz = __getpagesize ();
>>> + ?if (sz < 64 * 1024)
>>> + ? ? ? ? sz = 64 * 1024;
>>
>> Should this be PTHREAD_STACK_MIN instead to allow for per-machine
>> variations? Is it sufficient to use PTHREAD_STACK_MIN?
>
> We still need to take __getpagesize() into account, because some
> PTHREAD_STACK_MIN definitions are smaller than the largest possible
> page size on the respective architecture.

This looks good to me, please check this in.

The pedant inside of me says that this is wrong and that
PTHREAD_STACK_MIN should be sufficient. Unforutnately the more
fundamental problem is that glibc treats stack as "stack +
implementation required space" and renders PTHREAD_STACK_MIN somewhat
broken in light of variable sized static TLS data. I'm going to
approach the Austin Group to get an answer for the question of "What
is stack?"

I'd be surprised if PTHREAD_STACK_MIN even works correctly in such
cases (less than a page) since you need a minimum size for a guard
(page aligned), MINIMAL_REST_STACK, and __static_tls_Size.

Cheers,
Carlos.