From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11001 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: Tue, 31 Jan 2017 14:44:52 -0800 Message-ID: <9a395da9-2b2a-8719-f12d-c140deb12e62@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> 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 1485902708 5512 195.159.176.226 (31 Jan 2017 22:45:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2017 22:45:08 +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-11016-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 31 23:45:04 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 1cYhAe-0001Gp-2t for gllmg-musl@m.gmane.org; Tue, 31 Jan 2017 23:45:04 +0100 Original-Received: (qmail 3920 invoked by uid 550); 31 Jan 2017 22:45:07 -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 3888 invoked from network); 31 Jan 2017 22:45:06 -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=H8C30kIUeUF7xt7a4MMqzBWFmzaGqK60nF2hiEYMzqs=; b=WaMIeQk1EX6uE8huRLhMwnLDaThthMLaw6tQKW7WXBxDF8ASmBNtPC8bGwV9IKkJ8B 96ga/ON7Nc5KLV28XjBqUkN2FeN+1G/vwRLe3SD/Cah8tamSs1vFJP82N/TDyaaYC3f4 Zj69qlr38uPwiZCu4ft1yEHQ1eDdTBDkpt8jmw1uCN6sMuHGHCgmhc0UGupDd+xUelkF yVxL5oH0chl6IzU2axR06mk8LyqyaJHFzoP48SEKwwab0JuYGWFLgPwDSgA990/hU3yc VCl44Mjxnhxy/ouObs+7BWWTxktQPeejwfyllrigACm09QznR+qB5aJm2tYDYViuCjWs qzrw== 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=H8C30kIUeUF7xt7a4MMqzBWFmzaGqK60nF2hiEYMzqs=; b=tUoirQkE4kNEE1nnzvdu9W2cHH2lNJ7z/A4FXKXHhQPGBi2BIZdDI4JkPax1C4bEwN dySt/tHGq26LfOO1//ThGyEi0WygdJ4sv/CbTXJQAOsob9v7N4JH6ELQOgD5xiUuVqo4 M83yT6CKJHDOuHEE3/jLaP0EFGEAaXI7B7SGbN9jy9kAqwqHCycD0aqIAj3nDZfizeOo QxaJ8jR4Etd41f+cwJiQKp379RbPv9aZyAnjkUmrWobzd6jSkMwU4F2W8/yEJdjW7Egk 9oT3iof5p8v2zXFhq7FEsCDAYQ9Xz0jUV+kwWi1LVXTlLA3OF7hAh/Xn2KVI47U/KEwv 8iJA== X-Gm-Message-State: AIkVDXIB66FVXP4OksFdcewyxMdQEq2WbDa8QnzsiDzFRII2bEDmw/4lOTFnwvmwm1R+Cw== X-Received: by 10.98.15.143 with SMTP id 15mr32306633pfp.100.1485902694241; Tue, 31 Jan 2017 14:44:54 -0800 (PST) In-Reply-To: <037fdb37-b8d3-e79d-4baf-e2581c8900bf@gmail.com> Xref: news.gmane.org gmane.linux.lib.musl.general:11001 Archived-At: On 1/31/17 1:18 PM, Eric Hassold wrote: > > 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 > 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? Eric