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: Rich Felker <dalias at libc dot org>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, James Greenhalgh <james dot greenhalgh at arm dot com>, nd at arm dot com, GNU C Library <libc-alpha at sourceware dot org>, Jeff Law <law at redhat dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Date: Tue, 19 Dec 2017 15:34:01 -0500
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <5A1EFF28.9050406@arm.com> <5c796246-1907-8cf4-00fc-eee11614b092@redhat.com> <20171129205148.GG1627@brightrain.aerifal.cx> <00c123b5-dd46-6777-2c24-d80eae8d35df@redhat.com> <20171205105530.GA12966@arm.com> <20171219123446.GA34598@arm.com> <b30dad4e-948c-7d53-b704-d59867f1dcf7@redhat.com> <5A3958AC.6070700@arm.com>
On Tue, Dec 19, 2017 at 06:21:32PM +0000, Szabolcs Nagy wrote:
> On 19/12/17 13:06, Florian Weimer wrote:
> > On 12/19/2017 01:34 PM, James Greenhalgh wrote:
> >
> >> Option 1: 64k guard pages for LP64 on AArch64.
> >
> >> Option 2: 4k guard pages for LP64 for AArch64
> >
> >> Our proposal then, having spoken things through with the Arm engineers
> >> here, and taken in to consideration the opinions on this thread, is that
> >> we move to two "blessed" configurations of the GCC support for AArch64.
> >
> > Are there any Arm engineers who prefer Option 2, or is that just there to accommodate feedback on libc-alpha?
> >
> > My main concern was the variance in configurations with Option 1 (compared to Option 2). To some extent, the
> > variance with Option 1 is temporary. If both Option 1 and 2 are offered, we have permanent variance. From my
> > point of view, that's worth that just going with Option 1.
> >
> > So if this is some sort of consensus proposal, as opposed to actual technical requirements which favor Option 2
> > in some deployments, I think that's not a good idea, and we should go with Option 1 instead.
> >
>
> well glibc can pretend that only Option 1 is available,
> my latest patch assumes 64k probe interval:
> https://sourceware.org/ml/libc-alpha/2017-12/msg00451.html
>
> however Option 1 requires generic code to be changed
> for aarch64 only (in the libc and elsewhere) and we
> cannot easily do that on all (non-glibc) systems.
>
> it seems to me if there are systems where Option 1
> may not provide guaranteed trap on stack overflow
> then gcc should have Option 2 for those systems.
For what it's worth, I would prefer having the assumed minimum guard
size be 4k for musl targets. Even if we do increase the default guard
to 64k for 64-bit archs (seems likely), applications that manually set
it lower for whatever reason should still be handled safely.
I'm utterly unconvinced that there's any practical measurable
performance difference either way, unless someone can demonstrate an
existing real-world program (not artificial benchmark) where the
difference is measurable.
Rich