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

[Florian Weimer <fweimer at redhat dot 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