This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Quick access to stack bounds
> The problem with the PROT_GROWS* code is that it doesn't reserve the
> VMA. I cannot, because it can grow indefinitely, if necessary. It just
> extends the region when needed and based on heuristics (I *think* they
> handle the case where the jump is large enough to skip a page).
There are no heuristics, just rlimit constraints.
What could there be? alloca(1<<20) is kosher.
> Anyway, as I said this code cannot be used at all. The kernel can
> allocate other VMA blocking the extension making the execution
> unpredictable at best. In worse cases it'll result in silent
> overwriting.
Indeed. Given big jumps, even so with a red zone.
> If you propose a kernel change get rid of PROT_GROWS* at the same time.
What do you have in mind? A mapping of RLIMIT_STACK size with a flag about
not precommitting any pages before faulting them in?
> What are your plans for the initial thread having an unlimited stack?
> What is the stack size or stack base address?
Indeedy.
Thanks,
Roland