This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
ping: [PATCH 2/2][BZ #12416] Use stack boundaries from/proc/PID/maps to make stack executable
ping?
On Wed, 16 May 2012 12:33:38 +0530, Siddhesh wrote:
> 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.