Re: Fixed size of thread stacks in the nptl pthread implementation

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Fri, Feb 3, 2012 at 10:48 PM, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> On Fri, Feb 03, 2012 at 03:38:31PM +0530, Siddhesh Poyarekar wrote:
>> stacks and the main thread stack behave and look. Among other things,
>> the major difference for glibc would be that the stack can grow
>> automatically like the main thread. Is there any reason why this
>
> I guess the thread stack growth won't happen unless the guardsize is 0
> or if the program intentionally skips over the guard pages since the
> guard pages will stop the growth with a segfault. I could not see any
> unintentional side-effects otherwise of this change. Can someone
> please confirm that?

The default is to use a 1-byte guard which always rounds up to a
1-page guard. Currently glibc does not support dynamically growing
thread stacks. The guard would prevent the thread from easily using
any memory beyond the originally allocated amount. As the application
stack usage grows the thread will eventually try to use the guard
page(s) and fail, therefore the stack won't grow even if supported by
the kernel.

> On a related note, would glibc benefit if thread stacks were allowed
> to grow with the guard intact? This behaviour would be similar to the
> guard page for the process stack, except that we could be talking
> about guard pages instead of just a page.

Yes, I believe that support for a default where the stack grows might be useful.

If you call munmap on a region that was grown by the kernel will it
free the entire memory region including the additional pages?

For performance reasons glibc reuses stacks via a stack cache (fixed
cache size), if the stack grows, how will the implementation know the
new size? The internal stack cache size may grow unbounded, which
isn't a huge problem, since it reflects the requirements of the
threads.

Moving the guard pages introduces a security risk for the thread, so
the thread would not be running during the expansion and moving of the
guard page.

Your idea seems sound and useful.

You might want to ask on the Austin Group Mailing list if anything
would prevent a conforming POSIX implementation from having a growing
stack as the default (I say default because that's the only case where
the implementation has control over the creation of the stack space)?

Cheers,
Carlos.