Quick access to stack bounds

[Roland McGrath]

> 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