This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
to >=posix-2008)

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]