From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10993 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 18:13:21 -0500 Message-ID: <20170130231321.GO1533@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> <81f188cf-3fb8-2899-5c24-ec72d38ad300@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 1485818015 30402 195.159.176.226 (30 Jan 2017 23:13:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2017 23:13:35 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11008-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 31 00:13:32 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 1cYL8c-0007lU-Dn for gllmg-musl@m.gmane.org; Tue, 31 Jan 2017 00:13:30 +0100 Original-Received: (qmail 23711 invoked by uid 550); 30 Jan 2017 23:13:33 -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 23689 invoked from network); 30 Jan 2017 23:13:33 -0000 Content-Disposition: inline In-Reply-To: <81f188cf-3fb8-2899-5c24-ec72d38ad300@gmail.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10993 Archived-At: On Mon, Jan 30, 2017 at 01:30:00PM -0800, Eric Hassold wrote: > >>>>>This occurs because of call to mprotect() in pthread_create fails. > >>>>>In current implementation, if guard size is non null, memory for > >>>>>(guard + stack + ...) is first allocated (mmap'ed) with no > >>>>>accessibility (PROT_NONE), then mprotect() is called to re-enable > >>>>>read/write access to (memory + guardsize). Since call to mprotect() > >>>>>systematically fails in this scenario (returning error code EINVAL), > >>>>>it is impossible to create thread. > >>>>Failure is ignored and the memory is assumed to be writable in this > >>>>case, since EINVAL is assumed to imply no MMU. Is this assumption > >>>>wrong in your case, and if so, can you explain why? > >>>In my case, devices exhibiting issue are not MMU-less, they are > >>>Cortex-A9 devices with valid mmu / page protection working as > >>>expected otherwise. Note that current Musl code assumes ENOSYS means > >>>no MMU and handles it by assuming the system has no page protection > >>>at all. For the case I observe, it is EINVAL which is returned, this > >>>is not ignored, so memory is unmap'ed and pthread_create() fails. > >>In that case I think this is a kernel bug. Do you know why EINVAL is > >>happening? If there's an MMU, Linux should be able to replace the > >>anon PROT_NONE pages with anon RW pages. > > > >Agree. Unfortunately, those are devices we don't built the kernel > >for, so have been hardly able to track issue deeper. The point is > >however that such devices with this issue in kernel might not be > >that uncommon, and it concretely means impossibility at that > >moment to deploy on them a functional static executable built with > >musl. > [...] > Pinging... any comment, feedback or concern about latest version of > the patch, attached above, keeping current behavior but falling back > to (mmap(PROT_READ|PROT_WRITE) && mprotect(guard, none)) if and only > if current approach detected to fail) ? I still want to know what's going on on the kernel side, because it looks like this a rogue/nonsensical patch to the kernel that breaks mmap functionality in a general way that has nothing to do with the specific cpu/board. Rich