From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11002 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy 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:52:13 +0100 Message-ID: <20170201095212.GC12395@port70.net> 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> 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 1485942746 20037 195.159.176.226 (1 Feb 2017 09:52:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Feb 2017 09:52:26 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) To: musl@lists.openwall.com Original-X-From: musl-return-11017-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 01 10:52:23 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 1cYraQ-0004xT-HA for gllmg-musl@m.gmane.org; Wed, 01 Feb 2017 10:52:22 +0100 Original-Received: (qmail 25855 invoked by uid 550); 1 Feb 2017 09:52:25 -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 25834 invoked from network); 1 Feb 2017 09:52:24 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <9a395da9-2b2a-8719-f12d-c140deb12e62@gmail.com> Xref: news.gmane.org gmane.linux.lib.musl.general:11002 Archived-At: * 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. 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.