Re: [RFC] nptl: change default stack guard size of threads

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

On 29/11/17 15:18, Florian Weimer wrote:
> On 11/29/2017 03:59 PM, Szabolcs Nagy wrote:
>> The change can be made for aarch64 only
> 
> That doesn't seem to be the case, looking at the patch.
> 
> So what you intended to do, exactly?

it seems the issue applies to all targets, and since
glibc itself have 64k stack jumps i sent the rfc
patch for all targets to err on the safe side.

some targets will have 4k probe interval in gcc but
even those are not safe with existing binaries and
several targets have no proposed stack probe patch
as far as i understand.

> A 64 KiB probe interval on legacy 32-bit architectures is really a no-go.  It means we have to increase the
> guard region size to 64 KiB. But we cannot do that: The guard allocation comes out of the overall thread stack
> size, and existing applications do not expect that 60K of configured stack suddenly becomes unavailable. 
> Adding the guard size on top of the allocation will break setups which are carefully tuned for a maximum number
> of threads.

i was aware of the address space limitation on 32bit
but e.g. aarch64 ilp32 will need the 64k guardsize too.

(i think there are other 32bit targets that support
>4k page size, those may not mind the increase either,
they have to portably support large page size anyway)

i was not aware of bug 11787 and i agree that should
be fixed before the default guardsize is increased.

ARCH_GUARD_DEFAULT_SIZE is a macro that each target
can override so it can be set to 4k on legacy 32bit
targets or its default value can be changed for
__WORDSIZE == 32.

on aarch64 at least the default guard size should be
increased but it may even be better to enforce a minimum
64k guardsize if it is set to a non-zero value by the user.
i was not sure if that's acceptable (observably changing
what the user requested) hence this patch only touches
the default size.

this has implications to generic glibc behaviour
and that's where i'd like to see feedback, because
if there are issues then we may need to rethink
the aarch64 probing implementation in gcc.

e.g. user allocated stacks (thread or signal) cannot
be fixed, so if it is known common practice to allocate
those with single (or no) guard page then changing
glibc default does not solve the problem.