This is the mail archive of the libc-alpha@sourceware.org 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: 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


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