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

[Rich Felker <dalias at libc dot org>]

On Wed, Nov 29, 2017 at 09:44:14PM +0100, Florian Weimer wrote:
> On 11/29/2017 07:40 PM, Szabolcs Nagy wrote:
> >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.
> 
> glibc has many arbitrarily large stack jumps (although we've been
> eliminating them manually for a while).
> 
> What should guide the default size of the guard is not what glibc
> needs for its own routines, but what the stack probing in GCC needs
> to be correct.

Agreed.

> >>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.
> 
> Why?
> 
> This is a new feature.  Why make this less usable from the start?
> 
> (I don't care about aarc64 ILP32 and page sizes smaller than 64 KiB
> on aarch64 in general, so I wont argue this, and this is just a
> courtesy notification that what you are doing is Very Wrong Indeed.)

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.

> >(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)
> 
> GCC needs to emit probe intervals for the smallest supported page
> size on the the target architecture.  If it does not do that, we end
> up in trouble on the glibc side.

Agreed.

> 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?

Rich