From: Eric Hassold <hassold@gmail.com>
To: musl@lists.openwall.com
Subject: Re: Fix pthread_create on some devices failing to initialize guard area
Date: Tue, 31 Jan 2017 13:18:50 -0800 [thread overview]
Message-ID: <037fdb37-b8d3-e79d-4baf-e2581c8900bf@gmail.com> (raw)
In-Reply-To: <20170131035835.GP1533@brightrain.aerifal.cx>
On 1/30/17 7:58 PM, Rich Felker wrote:
> On Fri, Jan 20, 2017 at 02:42:01PM -0800, Eric Hassold wrote:
>> ----
>> [PATCH] set up guard protection after stack is mapped
>>
>> calling mprotect beyond the guard page of PROT_NONE mmap-ed stack fails on
>> some devices with buggy kernel, making it impossible to create
>> thread. if such condition is met, fall back to allocating memory
>> for stack and guard first, with read and write permission, then
>> protect guard
>> area.
>> ---
>> src/thread/pthread_create.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/thread/pthread_create.c b/src/thread/pthread_create.c
>> index 49f2f72..d3c030b 100644
>> --- a/src/thread/pthread_create.c
>> +++ b/src/thread/pthread_create.c
>> @@ -242,7 +242,17 @@ int __pthread_create(pthread_t *restrict res,
>> const pthread_attr_t *restrict att
>> if (__mprotect(map+guard, size-guard, PROT_READ|PROT_WRITE)
>> && errno != ENOSYS) {
>> __munmap(map, size);
>> - goto fail;
>> + if (errno == EINVAL) {
> In principle __munmap could have clobbered errno at this point. I
> don't think it will but to be safe errno should probably be saved.
>
>> + map = __mmap(0, size, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_ANON, -1, 0);
>> + if (map == MAP_FAILED) goto fail;
>> + if (__mprotect(map, guard, PROT_NONE)
>> + && errno != ENOSYS) {
>> + __munmap(map, size);
>> + goto fail;
>> + }
>> + } else {
>> + goto fail;
>> + }
> Can you try instead falling back to mmap with MAP_FIXED over top of
> the part that should be RW rather than unmapping and redoing the whole
> thing? If that works it would preserve the property of avoiding excess
> commit charge. If not then these kernels are very very broken. Either
> way it might shed some more light on what's going on. I understand you
> just want things to work, but I do also want to have some
> understanding of _why_ we're going to be working around something
> awful, if we really have to.
>
> Rich
mmap(MAP_FIXED) at the address returned by first mmap(PROT_NONE) and
then mprotect() indeed works.
BUT... actually kept exploring the idea that this might just be an issue
with page alignment. And found out that forcing the guard size to be
32k-aligned make current approach work well. So checked and found out
that on systems where issue happens, the actual page size determined
dynamically at runtime (using "getinfo PAGESIZE", and confirmed using
ratio of Mapped memory / nr_mapped pages from /proc/vmstat) is indeed
32k, whereas Musl has an hardcoded at compile time 4k page size for arm
architecture (with same eventually incorrect value returned by
getpagesize() and sysconf(__SC_PAGESIZE)).
Long story short, no odd behavior of the mmap in kernel, but Musl not
supporting correctly non-4k page systems, impacting pthread_create but
probably also malloc and mprotect. Given non-4k page systems are getting
more and more common (on arm and arm64 architectures at least), this
might be an important issue to fix. Should I start new "support for
non-4k page systems" discussion here ?
Eric
next prev parent reply other threads:[~2017-01-31 21:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 19:45 Eric Hassold
2017-01-20 19:56 ` Rich Felker
2017-01-20 21:04 ` Eric Hassold
2017-01-20 21:29 ` Rich Felker
2017-01-20 22:42 ` Eric Hassold
2017-01-30 21:30 ` Eric Hassold
2017-01-30 23:13 ` Rich Felker
2017-01-31 2:52 ` Eric Hassold
2017-01-31 3:58 ` Rich Felker
2017-01-31 21:18 ` Eric Hassold [this message]
2017-01-31 22:44 ` Eric Hassold
2017-02-01 9:52 ` Szabolcs Nagy
2017-02-01 18:21 ` Eric Hassold
2017-02-01 18:35 ` Rich Felker
2017-02-01 18:52 ` Eric Hassold
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=037fdb37-b8d3-e79d-4baf-e2581c8900bf@gmail.com \
--to=hassold@gmail.com \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).