From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10912 Path: news.gmane.org!.POSTED!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] malloc: always fail with ENOMEM Date: Mon, 9 Jan 2017 13:53:50 +0300 (MSK) Message-ID: References: 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 1483959293 27421 195.159.176.226 (9 Jan 2017 10:54:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Jan 2017 10:54:53 +0000 (UTC) User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) To: musl@lists.openwall.com Original-X-From: musl-return-10925-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 09 11:54:48 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 1cQXbC-0006RV-H7 for gllmg-musl@m.gmane.org; Mon, 09 Jan 2017 11:54:46 +0100 Original-Received: (qmail 13824 invoked by uid 550); 9 Jan 2017 10:54:47 -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 13806 invoked from network); 9 Jan 2017 10:54:47 -0000 In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:10912 Archived-At: On Mon, 9 Jan 2017, Julien Ramseier wrote: > malloc may set errno to something else than ENOMEM indirectly > through mmap, though ENOMEM is the only error allowed by POSIX. Pedantically speaking, no: POSIX explicitly allows implementations to report errors other than specified, in case errors are allowed; from 2.3 "Error Numbers": Implementations [...] may generate additional errors unless explicitly disallowed for a particular function. But this is just FYI, of course reporting EPERM from malloc is not useful (and Rich indicated that he'd like to avoid that). > There are cases where mmap will return EPERM instead of ENOMEM, > as highlighted by libc-test[1]. This can happen when mmap tries to > map pages near `mmap_min_addr` [2][3], as a security measure. > > [1] http://www.openwall.com/lists/musl/2016/03/30/9 > [2] https://ghc.haskell.org/trac/ghc/ticket/7500 > [3] https://github.com/torvalds/linux/blob/master/security/min_addr.c Thanks for digging out the cause. I think you should wait for feedback from Rich on the patch. Alexander