This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> 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. 

Yes, that makes sense.  (I don't think I'd thought about it before.)

> Whether or not the mapping above is anonymous should not matter in that
> case.

Right.  On a _STACK_GROWS_DOWN machine, whatever is above the stack has no
bearing on the size of the stack.

> 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.

Certainly for the test we could make it set its own rlimit to something
with predictable behavior if that makes the test more coherent.

But I think this change is now fine as it is.  Go ahead and commit it.
If anybody notices inconsistent results in the test, we can reconsider
changing it later.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]