mailing list of musl libc
 help / color / mirror / code / Atom feed
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: Wed, 1 Feb 2017 10:21:40 -0800	[thread overview]
Message-ID: <72295197-bf76-b661-dcd6-6d34493a0ac0@gmail.com> (raw)
In-Reply-To: <20170201095212.GC12395@port70.net>


On 2/1/17 1:52 AM, Szabolcs Nagy wrote:
> * Eric Hassold <hassold@gmail.com> [2017-01-31 14:44:52 -0800]:
>> On 1/31/17 1:18 PM, Eric Hassold wrote:
>>> 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
>>>
>> Just removing the "#define PAGE_SIZE 4096" from arch/arm/bits/limits.h makes
>> PAGE_SIZE to be defined by internal/libc.h as libc.page_size which is
>> initialized correctly at runtime, making the correct page size be used all
>> around musl. Since a page size of 4k is no more a valid assumption on
>> arm-linux target, is removing this compile time define a right fix?
> it is ok to remove PAGE_SIZE but i thought arm elf
> binaries would depend on the 4k page size.. making it
> less useful to support other page sizes, but if 32k
> works in practice then i think musl should support it.

Binutils was updated couple years ago to support up to 64KB page size 
and default text alignment to 64kB boundary for armel and match changes 
in kernel:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89

So yes, executables built with older toolchains can't be deployed as is 
on such 32kB pagesize systems, but no issue with with executables built 
with recent  (binutils 2.27 && gcc 5.4) toolchain we are using.

Any further action on my side to proceed? I guess no much value in 
submitting a patch though mail here for such one liner change...

Eric

>
> i guess the boundary of unaligned sections will be
> mapped twice which is not a big issue except may be
> you don't get relro support if the readonly relocs
> are 4k aligned.



  reply	other threads:[~2017-02-01 18:21 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
2017-01-31 22:44             ` Eric Hassold
2017-02-01  9:52               ` Szabolcs Nagy
2017-02-01 18:21                 ` Eric Hassold [this message]
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=72295197-bf76-b661-dcd6-6d34493a0ac0@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).