From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v5] Add a test case for mmap MAP_GROWSDOWN flag
Date: Fri, 11 Sep 2020 16:57:30 +0200 [thread overview]
Message-ID: <20200911145730.GA6157@yuki.lan> (raw)
In-Reply-To: <CAEemH2fPRTh6drs=h=U7OG07SZDgpDfEB0xRadF8Y1FbaHR8Nw@mail.gmail.com>
Hi!
> > Well it's not wrong per se but as it is we do not use the pre-allocated
> > part of the stack at all, we directly jump for the guard page as we use
> >
>
> Really? But I think the pthread_attr_setstack(&attr, stack, stack_size) will
> take use of the whole stack memory in function recursive performing.
> How can we say NOT use the pre-allocated stack? I fell a bit confused
> about your words here.
I've been confused as well I looked at pthread_attr_setstack() function
manual and it's expecting to get the lowest pointer of the stack. So I
suppose that the stack really started at the stack + stack_size address.
But still the code wasn't exactly right, because the lowest address of
the stack in the previous code was stack - stack_size, which would be
start of the unmapped region and the size of the stack would be 2 *
stack_size, as we expected the mapping to grow.
> > There is no point in adding size * 2 here. We can as well reserve 256 *
> > page_size + size. Then map() a single page at the end, which would be at
> > start + total_size - page_size and finally return start + total_size
> > from this function and pass that to pthread_attr_setstack().
> >
>
> I guess that will be work, but sounds a bit stingy. Since the modern system
> does not short of such memory for testing:). And if we decide to go with
> this, the code design comments above should be all rewrite.
I do find this layout to be a bit more straighforward.
> >
> > That way it would look like:
> >
> > | 256 pages | unmapped | 1 mapped page |
> >
> > | - - - stack_size - - - |
> >
> >
> > > + /* Test 2 */
> > > + child_pid = SAFE_FORK();
> > > + if (!child_pid) {
> > > + tst_no_corefile(0);
> > ^
> > This should go to the test setup.
> >
>
> Only the child_2 will get SIGSEGV, why should we move it to affect the
> whole test?
It's not like we do expect any part of the test to produce core-dump so
there is no point in disabling them on each iteration only for the
child. But I guess that it's fine either way.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2020-09-11 14:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 3:55 [LTP] [PATCH v5] Add a test case for mmap MAP_GROWSDOWN flag Li Wang
2020-09-11 7:05 ` Petr Vorel
2020-09-11 7:42 ` Li Wang
2020-09-11 13:08 ` Cyril Hrubis
2020-09-11 14:41 ` Li Wang
2020-09-11 14:57 ` Cyril Hrubis [this message]
2020-09-14 3:06 ` Li Wang
2020-09-14 3:40 ` Li Wang
2020-09-15 13:40 ` Cyril Hrubis
2020-09-18 11:43 ` Cyril Hrubis
2020-09-18 15:00 ` Li Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200911145730.GA6157@yuki.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.