From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10995 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: Mon, 30 Jan 2017 22:58:35 -0500 Message-ID: <20170131035835.GP1533@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> 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 1485835142 29706 195.159.176.226 (31 Jan 2017 03:59:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2017 03:59:02 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11010-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 31 04:58:59 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 1cYPas-0007XJ-C6 for gllmg-musl@m.gmane.org; Tue, 31 Jan 2017 04:58:58 +0100 Original-Received: (qmail 18325 invoked by uid 550); 31 Jan 2017 03:59:01 -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 18264 invoked from network); 31 Jan 2017 03:58:59 -0000 Content-Disposition: inline In-Reply-To: <80ab9b97-dc0d-e642-cbf1-1b20e1cddf64@gmail.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10995 Archived-At: 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