From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11004 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Hassold Newsgroups: gmane.linux.lib.musl.general Subject: Re: Fix pthread_create on some devices failing to initialize guard area Date: Wed, 1 Feb 2017 10:21:40 -0800 Message-ID: <72295197-bf76-b661-dcd6-6d34493a0ac0@gmail.com> References: <20170120195649.GS1533@brightrain.aerifal.cx> <30588c41-eb3d-627e-c5eb-91e19ef56790@gmail.com> <20170120212933.GT1533@brightrain.aerifal.cx> <80ab9b97-dc0d-e642-cbf1-1b20e1cddf64@gmail.com> <20170131035835.GP1533@brightrain.aerifal.cx> <037fdb37-b8d3-e79d-4baf-e2581c8900bf@gmail.com> <9a395da9-2b2a-8719-f12d-c140deb12e62@gmail.com> <20170201095212.GC12395@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1485973317 10966 195.159.176.226 (1 Feb 2017 18:21:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Feb 2017 18:21:57 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 To: musl@lists.openwall.com Original-X-From: musl-return-11019-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 01 19:21:52 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cYzXT-0002eP-Sg for gllmg-musl@m.gmane.org; Wed, 01 Feb 2017 19:21:51 +0100 Original-Received: (qmail 28103 invoked by uid 550); 1 Feb 2017 18:21:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 28079 invoked from network); 1 Feb 2017 18:21:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=3PG27WD3SMIf15BRVcmpukwV2dmxretgykVk5fbEzYw=; b=qGXwTlftSJYPPzWCHImAs88t+HAosYuoD58bVxnWA1O5jI8oYSl4jjqhfU/ZWUrzJw Q8Ub44eYdsxUmWZ/P7ZV3nDSoAhtDaPPrEV8Zqs63uEBtxWBNNojDnJkGTvdJVTzG9RK letODL8YdBjIwxFZVo98WbFSxoiTUmIsBHHR9BhaqZCda7S8JieLYfKhNQq5QtQgBVqb WdAbV6RlDL5Yw4qS98D2RqSY2QNsMVWDcni727PNzLEcmioSnwGJRvgzB4qTfanCJ2EK JdQlHJ00qsc/8x3gyUeoxgL9Oh+6sBLMOmV9INkZXwZVcRQJQawHqhzbiGXnC9I13DLV VWCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3PG27WD3SMIf15BRVcmpukwV2dmxretgykVk5fbEzYw=; b=T0yJvjM8Ff4ABNn4hBRoQWd/8in73d70yrEz42d95bp7YanAsolXRi+sXRXdhSwQBf SDV2urWnJNdq6p51jmJZrTexgzvofUV3KM70BDceyuNrdd/Md1g1ASR51ZyBC244h4Ab KbJM4f4D939tFPZvI3lCcOh0ObrPmtCwPSSAAqIGiN4LTIb7BnP2ZTuON76v6tOMC9c4 m6Dm8LptDSwtP4YAOhP63HjpIHniFrxeKuAqq7NRSN2SzdVFxjvUFS3VCrWB7kAn+JWd Q9siYBXbZoCghlzwdGgLLuinVs/KexlUkwU46MtwKl2RJikVI/WIleR9L/nBnC4uGhV+ FKMw== X-Gm-Message-State: AIkVDXJRer3qhE6hi1motraYpvU31whAp5Tn3cipq0vC+IVqnc4Yk7Ng3FQoyyvlrfl1Nw== X-Received: by 10.98.36.134 with SMTP id k6mr5130622pfk.41.1485973301697; Wed, 01 Feb 2017 10:21:41 -0800 (PST) In-Reply-To: <20170201095212.GC12395@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:11004 Archived-At: On 2/1/17 1:52 AM, Szabolcs Nagy wrote: > * Eric Hassold [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.