From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11000 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 13:18:50 -0800 Message-ID: <037fdb37-b8d3-e79d-4baf-e2581c8900bf@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> 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 1485897545 30663 195.159.176.226 (31 Jan 2017 21:19:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2017 21:19:05 +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-11015-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 31 22:19:02 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 1cYfpN-0007if-UP for gllmg-musl@m.gmane.org; Tue, 31 Jan 2017 22:19:02 +0100 Original-Received: (qmail 11678 invoked by uid 550); 31 Jan 2017 21:19:05 -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 11645 invoked from network); 31 Jan 2017 21:19:04 -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=aUX/egF4IOgmXX5D5YsLVSFuF7SAnrsEpes0A0S+WxQ=; b=MxyirPfaJa+lLTDjYmc+ZuaYyjFPFobO6tXC3wo4C1DR5tsfTbiIjoHEpeVHF1Snuf FruszB/7Wr72FJbpTk2psrYJfyTITWjfgJ6JHH9A/WnrSneu8Y1ZgMApYwfZGfey0ku6 BEO5XGrEFyM6WNvfT6cAryEaLen4Qo+lg2+VA1Gc81ZveMYbrglty4xqNKSu0CZvhYg4 pY4KkpF2faTUboN5ubuyLw/WuuuMM/joe5oYirQzTvmSaxzGFlLy0jrHRZZjoa3kaQic 4Oj2IAGF30JPZPJwWbTA/LNq2W68MDFsFMrD8DBObjuepOPHaIU5f5GgwnYRp+/ml0Ia 4qqg== 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=aUX/egF4IOgmXX5D5YsLVSFuF7SAnrsEpes0A0S+WxQ=; b=ehzPwTEgIa/3T6HnpNVJ7nemLvewhTnKyOXi9qiplCYXyDp2a5mSgIUddLDxfeuog6 H1O3n5hM/f0wDqxBnDb4I5+y5Rb7gXV/HQYVM9mPnxxUIUIvKsWRUz0wKQ/j7Svfge9w PC/8Bk5CgvDhJoh3O/XHCDVKpCZ3hUdbDDbFLRnUb39zbv7DiCSUcKIkBc8wV/oUCzIn u9Dm6o7jP7MlH+EEWvlrVQsa4uiyI8f7DWl0sMIpLDzy1kh5VcdUHt6D54xkNcDN0MQy w6V7rUlsj9Uh8pT5zih9SvhDoRAmrB6kRBuYC5VJVb+KSVgUNL0y6KJlMYgalO7AZ+J/ e4Zg== X-Gm-Message-State: AIkVDXIcalFrKlLbLCFUOE0R/OfhMW+5jQepaXji/6teoc7sPmroqsD21RWSakQgF/bB1g== X-Received: by 10.98.20.81 with SMTP id 78mr31277694pfu.171.1485897531991; Tue, 31 Jan 2017 13:18:51 -0800 (PST) In-Reply-To: <20170131035835.GP1533@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11000 Archived-At: 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