[PATCH 2/2][BZ #12416] Use stack boundaries from /proc/PID/maps to make stack executable

[Siddhesh Poyarekar]

On Tue, 15 May 2012 09:30:33 -0700 (PDT), Roland wrote:
> Do you mean just below the stack (lower address)?  If it's actually
> the dlopen'd module, then that is a file mapping rather than an
> anonymous mapping like the stack.  You can distinguish those in
> /proc/self/maps (the fourth column is 00:00 for anonymous mappings and
> not that for file mappings).  So pthread_getattr_np need never be
> confused by that case.

Yes I meant below, sorry about that.

I interpreted the pthread_getattr_np logic to consider the end of
previous vma for stack size to mean that we're looking at the potential
for the stack to grow, subject to rlimit. Whether or not the mapping
above is anonymous should not matter in that case. If we consider that
the file mapping happens below the stack, the potential for growth of
the stack changes to the end of that mapping and if rlimit is high
enough, it will change the stacksize and stackaddr returned.

I've attached an updated patch with the rest of the changes. If we
don't want to account for a too high rlimit (that is a pre-requisite
for this situation to occur) then I can change the check to individual
verification of stack size and stack address and send an updated patch.

Thanks,
Siddhesh

ChangeLog:

2012-05-16  Siddhesh Poyarekar  <siddhesh@redhat.com>

	* elf/tst-execstack.c: Include stackinfo.h.
	(do_test): Adjust test case to ensure that pthread_getattr_np
	behaviour remains the same after marking stack executable.

nptl/ChangeLog:

2012-05-16  Siddhesh Poyarekar  <siddhesh@redhat.com>

	* nptl/pthread_getattr_np.c (pthread_getattr_np): Use
	__libc_stack_end rounded to the end of containing page as the
	real stack end.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-inconsistency-in-stack-bottom.patch
Type: text/x-patch
Size: 4083 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120516/4891704e/attachment.bin>