[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