Re: [PATCH 2/2][BZ #12416] Use stack boundaries from /proc/PID/mapsto make stack executable

[Roland McGrath <roland at hack dot frob dot com>]

> > Why don't you just use #if _STACK_GROWS_{DOWN,UP} here?
> 
> The macro is defined only within the glibc sources in stackinfo.h. I
> reckoned that test cases should be using only publicly available
> interfaces within glibc, which is why I wrote this instead. Is it OK
> to use stackinfo.h here?

It is generally OK to use internal headers in libc tests if that is the
cleanest thing.  It's ideal not to, but it's better than making the test
fragile or convoluted just to avoid it.

> > This says we're not checking them separately but doesn't really say
> > why, or at least not clearly enough for me.  If it's really the case
> > that the two could change such that their sum/difference remains the
> > same and that would be kosher, then explain it more thoroughly.  If
> > not, then just check them separately.
> 
> It is possible that the dlopen'd module may have been mmapped just
> above the stack. The stack size is taken as MIN(stack rlimit size, end
> of last vma) in pthread_getattr_np, so it is possible that the size
> may have changed as a result if the rlimit is set high enough.

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.

I guess it's true that another anonymous mapping could come in
immediately below the stack.  pthread_getattr_np would not be able to
distinguish that from the stack vma just having been split for some
reason.  But that might be impossible in the test case.  I suppose the
act of dlopen will entail some malloc and it's always possible that
would wind up doing an anonymous mmap, so in theory it could be hit.
But in reality, there should be little enough malloc'd in this test
case that it will all go in the sbrk area, so I don't think this will
ever come up in this test.  Do you think otherwise?

> A subsequent call to pthread_attr_getstack returns the size and
> (bottom - size) as the stacksize and stackaddr respectively. Due to the
> above it is clear that if size changes due to the new mapping, then both
> stacksize and stackaddr can change, but the stack bottom should remain
> the same, which is nothing but stackaddr + stacksize.

The comments in the test should explain this rationale.


Thanks,
Roland