This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] nptl: change default stack guard size of threads
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>, Jeff Law <law at redhat dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Rich Felker <dalias at libc dot org>, James Greenhalgh <James dot Greenhalgh at arm dot com>
- Date: Wed, 29 Nov 2017 22:28:49 +0000
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco dot Dijkstra at arm dot com;
- Nodisclaimer: True
- References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <5A1EFF28.9050406@arm.com>,<5c796246-1907-8cf4-00fc-eee11614b092@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Florian Weimer wrote:
> 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.
It's not related to what GLIBC needs, but GLIBC, like Linux, must continue to
run old binaries so a larger guard size is definitely beneficial. No existing code
uses probing, so increasing the guard size means far fewer functions could
jump the guard. The dropoff is exponential, each doubling of guard page size
halves the number of functions with a stack larger than the guard size. That's
why Linux went for a 1MB guard size. A larger thread guard size could be the
default on 64-bit targets or a per-target choice depending on whether they
want to improve safety.
> > 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?
> 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.
> > 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.
Probing without a guard page is equivalent to no probing. So for these
cases we're simply unprotected.
Wilco