This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] nptl: change default stack guard size of threads
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Jeff Law <law at redhat dot com>, James Greenhalgh <james dot greenhalgh at arm dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: nd at arm dot com, Rich Felker <dalias at libc dot org>, GNU C Library <libc-alpha at sourceware dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Date: Tue, 12 Dec 2017 11:42:51 +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=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <5A1ECB40.firstname.lastname@example.org> <email@example.com> <5A1EFF28.firstname.lastname@example.org> <email@example.com> <20171129205148.GG1627@brightrain.aerifal.cx> <firstname.lastname@example.org> <20171205105530.GA12966@arm.com> <email@example.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 11/12/17 23:49, Jeff Law wrote:
> On 12/05/2017 03:55 AM, James Greenhalgh wrote:
>>>> 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.
>> This is where I may have a misunderstanding, why would it require probing
>> at the smallest page size, rather than probing at a multiple of the guard
>> size? It is very likely I'm missing something here as I don't know the glibc
>> side of this at all.
> I'm not sure where that statement comes from either. I guess the
> concern is someone could boot a kernel with a smaller page size and
> perhaps the kernel/glibc create their guards based on # pages rather
> than absolute size. Thus booting a kernel with a smaller pagesize would
> code with less protection.
historically posix required a single page guard at the
end of thread stacks, that's what all existing libcs
implement and glibc internally assumes this at several
places where stack/guard size accounting happens.
(so larger guard is not conform to posix-2004, only
users can also set the guard size explicitly when creating
threads (at least openjdk and erlang do this for threads
that call c code) and that's not something glibc can change:
it is allowed to round this up to pagesize but not to
some arbitrary larger value.
glibc has another problem that it does stack accounting
incorrectly and thus increasing the guard size can easily
make existing code fail with stack overflow and fixing
this is non-trivial since many users already expect the
buggy behaviour (with glibc specific workarounds)
(i would not expect many breakage in practice because of
this, but it does make the guard size change harder to
agree on on the glibc side and making the logic target
specific has another set of issues)
in short, the existing posix ecosystem assumes a single
page guard all over the place, doing the probing at
larger intervals than the minimum page size will leave
holes, many of which glibc cannot fix and the ones it
can will leave glibc maintenance issues behind.