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

[Rich Felker <dalias at libc dot org>]

On Wed, Nov 29, 2017 at 10:28:49PM +0000, Wilco Dijkstra wrote:
> > > 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?
> 
> Why should it be any different from LP64? Typical page size will still be
> 64KB, so a 4KB guard would be rounded up to 64KB. An ILP32 system
> with 64KB pages could create  ~30000 threads per process. Does that
> make it unusable?

A large page size like 64k seriously impacts the usefulness of a
32-bit virtual address space. You're limited to at most 64k total
pages (assuming userspace can use the whole 4GB which is likely if
it's 64-bit kernel/hardware, but not if it's 32-bit), essentially zero
bits of randomness for ASLR, etc. I understand that there's a trend to
favor larger page sizes to mitigate TLB pressure in huge software; I
don't think there's been nearly enough consideration of the negative
consequences of this trend.

> > 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.
> 
> Smallest supported page size on Arm is 1KB. Should that dictate
> everything? It's an ABI choice, not something directly related to
> smallest page size.

For the purposes of this discussion, hardware-supported page sizes
that are not compatible with the ABI page size are not relevant. For
example SYS_mmap2 cannot represent 1k pages so they're not a
possibility with the ABI. Also, runtime page sizes larger than the ELF
segment alignment are not compatible with the ABI.

Rich