This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] nptl: change default stack guard size of threads
- From: Rich Felker <dalias at libc dot org>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, nd at arm dot com, Jeff Law <law at redhat dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, James Greenhalgh <James dot Greenhalgh at arm dot com>
- Date: Wed, 6 Dec 2017 17:07:51 -0500
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- References: <5A1ECB40.email@example.com> <firstname.lastname@example.org> <5A1EFF28.email@example.com> <firstname.lastname@example.org> <HE1PR0801MB205834BDB77C2208C953FD2E833B0@HE1PR0801MB2058.eurprd08.prod.outlook.com> <email@example.com> <DB6PR0801MB20537C3F43D7C428E5EEE77583320@DB6PR0801MB2053.eurprd08.prod.outlook.com> <5A2855F9.firstname.lastname@example.org>
On Wed, Dec 06, 2017 at 08:41:29PM +0000, Szabolcs Nagy wrote:
> On 06/12/17 14:27, Wilco Dijkstra wrote:
> > Florian Weimer wrote:
> >> On 11/29/2017 11:28 PM, Wilco Dijkstra wrote:
> >>> 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 not actually true in the sense that the math doesn't work out
> >> that way. If you have a weird function which skips by a really large
> >> amount, you can double the guard size many, many times until the number
> >> of unprotected functions drops further.
> >> And there is definitely a long tail here, due to GNU's affinity to
> >> variable-length arrays and alloca.
> > The math works fine for most of the curve. The measurements I did
> > show that the number of functions with really large stack allocations is
> > extremely small. So it's a long tail only in terms of maximum stack
> > allocation, not in number of functions.
> with 4k probe interval about 1% of functions need probes
> with 64k probe interval about 0.01% (order of magnitude,
> alloca not included), so increasing the default guard can
> be useful for existing code.
Rather than what % of all functions need probes, I think it would be
more meaningful to ask what % of functions with a useful (not trivial
error) code path less than N instructions (for N=100 or so) need
probes. My hypothesis is that, for either threshold 4k or 64k, the %
Of course this is a bit harder to measure but maybe there's some way
to do it? It would be nice if static analysis tools could report that
(they wouldn't exclude trivial error ones but some additional
heuristic or manual review pass could).