[LTP] LTP release
Li Wang
liwang@redhat.com
Thu Sep 10 09:12:14 CEST 2020
On Wed, Sep 9, 2020 at 9:13 PM Cyril Hrubis <chrubis@suse.cz> wrote:
> ...
> > static void split_unmapped_plus_stack(void *start, size_t size)
> > {
> > /* start start + size
> > * +---------------------+----------------------+-----------+
> > * + unmapped | mapped | 256 pages |
> > * +---------------------+----------------------+-----------+
> > * stack
> > */
>
> Shouldn't the 256 pages follow the unmapped part?
>
Yes, you're right. I made a mistake on draw that. Will fix in V4.
>
> If I'm not mistaken if stack grows down the address decreases with stack
> allocations, so it should be as:
>
> | 256 pages | unmapped | mapped |
>
>
> That would also mean that we should map the stack at address start +
> total_size - size if I'm not mistaken. I guess that we can put all the
> mess into a single function as well and have just allocate_stack() that
> will find a suitable address, mmap the stack together, splitting this
> into two functions is unnecessary confusing.
>
Good point, it makes sense to me.
>
> > stack = SAFE_MMAP(start + size, size, PROT_READ | PROT_WRITE,
> > MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS |
> > MAP_GROWSDOWN,
> > -1, 0);
> > }
>
> Also I would like to get rid of the -fno-optimize-sibling-calls in the
> Makefile, this makes the test a bit fragile and less portable.
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
>
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200910/52c12c26/attachment.htm>
More information about the ltp
mailing list