From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11005 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Fix pthread_create on some devices failing to initialize guard area Date: Wed, 1 Feb 2017 13:35:40 -0500 Message-ID: <20170201183540.GT1533@brightrain.aerifal.cx> 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> <72295197-bf76-b661-dcd6-6d34493a0ac0@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1485974157 16051 195.159.176.226 (1 Feb 2017 18:35:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Feb 2017 18:35:57 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11020-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 01 19:35:53 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 1cYzl1-0003tS-Um for gllmg-musl@m.gmane.org; Wed, 01 Feb 2017 19:35:52 +0100 Original-Received: (qmail 16201 invoked by uid 550); 1 Feb 2017 18:35:55 -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 16167 invoked from network); 1 Feb 2017 18:35:54 -0000 Content-Disposition: inline In-Reply-To: <72295197-bf76-b661-dcd6-6d34493a0ac0@gmail.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11005 Archived-At: On Wed, Feb 01, 2017 at 10:21:40AM -0800, Eric Hassold wrote: > > 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. OK, so this was a generalization of the ABI that we weren't aware about. Bleh. But if the rest of the world is no longer considering 4k page size part of the ABI, we should update musl to reflect this. > 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... No further action needed. Thanks for being patient with my hesitance to accept the initial patch and for working through this to find the real problem. Rich