This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Quick access to stack bounds
> Yes, and that's a problem With unlimited stacks and PROT_GROW* almost
> any invalid memory access can be interpreted to belong to a stack. This
> is why, I thought, there is something in the kernel to try to
> differentiate bogus accesses from extensions.
I don't see any code like that in the kernel.
> >> If you propose a kernel change get rid of PROT_GROWS* at the same time.
> >
> > What do you have in mind?
>
> As kernel extensions? Richard described the new AT_* constant to tell
> userlevel about the stack.
No, I thought you meant getting rid of VM_GROWSDOWN internally for the
initial stack vma. So I was asking what the plan for the main stack would
be if not what we have today.
> I was thinking about completely removing PROT_GROWS*. Nobody has used
> it in a decade, I bet.
I'm not entirely clear on which things you are referring to here.
1. PROT_GROWS* flags to mprotect
This does not change the growth behavior. It applies the mprotect
action to the whole stack vma rather than splitting it and applying the
new protections to only the given page range. i.e., if you use mprotect
PROT_ALL|PROT_GROWSDOWN on the stack vma, then PROT_EXEC applies to the
future growth pages too. It gets EINVAL if the vma you are touching is
not already marked GROWS{UP,DOWN} as appropriate--i.e. if it's something
other than the stack vma.
_dl_make_stack_executable uses this today.
2. MAP_GROWS* flags to mmap
With this you can make a fresh mapping that behaves like the initial
stack vma does. I don't know of any sensible use for this nor of
anything that uses it. (But I have not tried to search the universe.)
3. kernel-internal VM_GROWS* logic for implicit initial stack vma
To get rid of this would imply getting rid of #1 and #2 too, of course.
This is what I originally thought you were suggesting. If so, the
question is what the kernel should do instead for the implicit initial
stack vma. For RLIMIT_STACK that's not RLIM_INFINITY, the obvious
notion is what I posited: A mapping of RLIMIT_STACK size with a flag
about not precommitting any pages before faulting them in. (Or perhaps
no such flag, and/or perhaps just some madvise-equivalent hint about
sequential-downwards use patterns.)
> The remaining issue then would be unlimited stacks.
Yes, I don't really know what the plan would be for that.
Note that today's kernel notices whether RLIMIT_STACK is RLIM_INFINITY or
not and based on that chooses (once, at exec time) which algorithm to use
for map-anywhere (i.e. non-MAP_FIXED) mmap calls. If stack is infinite, it
chooses one that starts at a magic address and goes up from there; if stack
is finite, it chooses one that sticks things up near the base of the stack
and goes down from there.
Thanks,
Roland