Re: RFC PATCH: Don't use /proc/self/maps to calculate size of initial thread stack

[Florian Weimer <fweimer@redhat.com>]

* Zack Weinberg via Libc-alpha:

> When pthread_getattr_np is applied to the initial thread, it has to
> figure out how big the initial thread's stack is.  Since the initial
> thread's stack is lazily allocated and the kernel reuses that memory
> region for the "information block" (argv, environ, etc) there are
> several different ways one could define "the size of the initial
> thread's stack"; for many years, the NPTL implementation has said that
> the stack starts at __libc_stack_end, rounded in the opposite
> direction from stack growth to the nearest page boundary, and extends
> for getrlimit(RLIMIT_STACK).rlim_cur bytes, *minus the size of the
> information block*, which is beyond __libc_stack_end.  The rationale
> is that the resource limit is enforced against the entire memory area,
> so if we don't subtract the size of the information block, then the
> program will run out of stack a few pages before pthread_attr_getstack
> says it will.

Do we actually have to subtract the size of the information block?
One could argue that this is just part of the arguments passed to main,
so sort-of-but-not-quite part of main's stack frame.

process_vm_readv seems quite likely to get blocked by seccomp filters.

Maybe we can get the kernel to pass the end of the stack in the
auxiliary vector?

Thanks,
Florian