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

[Florian Weimer <fweimer at redhat dot com>]

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.

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

Isn't there are generic variant which covers at least alloca and VLAs?

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

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.

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

We have test cases which do not allocate a guard page for those, but 
with the existing probing algorithms I've seen, this is not actually a 
problem if stack usage is kept low.

Thanks,
Florian