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

[Florian Weimer <fweimer@redhat.com>]

On 11/29/2017 09:51 PM, Rich Felker wrote:

> I'm not sure I follow, but from the standpoint of virtual address
> space and what is an acceptable cost in wasted address space, any
> ILP32-on-64 ABIs should be considered the same as 32-bit archs. As
> such, I think GCC really needs to do the stack probe every 4k, not
> 64k, and the default (and certainly minimum-supported) guard size
> should be kept at 4k, not 64k or anything larger.

Yes, and I expect that we will keep using 4 KiB probing on i386 (and 
s390/s390x).  That's what Jeff gave me for testing.  I do hope the final 
upstream version isn't going to be different in this regard.

But in the end, this is up to the machine maintainers (for gcc and glibc).

>> We can throw new code at this problem and solve it for 64-bit.  For
>> 32-bit, we simply do not have a universally applicable solution.  My
>> understanding was that everywhere except on ARM, GCC was compatible
>> with the pioneering glibc/Linux work in this area (the guard page we
>> added to thread stacks, and the guard page added by the kernel).  If
>> this isn't the case, then I'm really disappointed in the disregard
>> of existing practice on the GCC side.
> 
> Hm? What are you thinking of that GCC might have gotten wrong?

Use 64 KiB probe intervals (almost) everywhere as an optimization.  I 
assumed the original RFC patch was motivated by that.

I knew that ARM would be broken because that's what the gcc ARM 
maintainers want.  I assumed that it was restricted to that, but now I'm 
worried that it's not.

Thanks,
Florian