From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-4.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12669 invoked from network); 19 Sep 2022 20:17:19 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 20:17:19 -0000 Received: (qmail 25984 invoked by uid 550); 19 Sep 2022 20:17:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 25949 invoked from network); 19 Sep 2022 20:17:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zhasha.com; s=wirbelwind; t=1663618622; bh=wL3JsCNKHv2iK71BDGzAt8reaOPzAY+jXxGE5DNYftI=; h=Date:From:To:Subject:In-Reply-To:References; b=wq3htW/nA5zJz6P/EQHH3bxv00wWjmG2UVVi2Us2kgdQGla+ctUwqA+I6XMjQQ1Us BCGS+9euvluTTIbcgURTye69nuuc5rm81f9JRiLeW8v9U7dTBx2CbMWCUli/jD+BzR 8D6GOlI77pd2rK7m/9F98ff9dQcKejVk25IcEj1o= Date: Mon, 19 Sep 2022 22:17:02 +0200 From: Joakim Sindholt To: musl@lists.openwall.com Message-Id: <20220919221702.2c8da85cc0638c2fdf43ac6a@zhasha.com> In-Reply-To: <2022092003453382350548@gmail.com> References: <2022091915532777412615@gmail.com> <20220919134319.GN9709@brightrain.aerifal.cx> <202209200132289145679@gmail.com> <20220919181556.GT9709@brightrain.aerifal.cx> <2022092002445709017731@gmail.com> <20220919191820.GU9709@brightrain.aerifal.cx> <2022092003453382350548@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) On Tue, 20 Sep 2022 03:45:35 +0800, baiyang wrote: > > The only correct value malloc_usable_size can return is the value you passed to the allocator. > > I don't think so, see: > > Linux man page: https://man7.org/linux/man-pages/man3/malloc_usable_size.3.html - "The value returned by malloc_usable_size() may be **greater than** the requested size of the allocation". > > Mac OS X man page: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/malloc_size.3.html - "The memory block size is always at least as large as the allocation it backs, **and may be larger**." > > FreeBSD man page: https://www.freebsd.org/cgi/man.cgi?query=malloc_usable_size&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html - "The return value **may be larger** than the size that was requested during allocation". > > These official man pages clearly state that the return value of malloc_usable_size is the size of the memory block allocated internally, not the size submitted by the user. > > Instead, we didn't find any documentation saying that the return value of malloc_usable_size must be the size submitted by the user to be correct. Please correct me if you have the relevant documentation. It's not that malloc_usable_size must return the size originally submitted by the user but that if it doesn't and you take that as an invitation to exceed the original size allocated you will hit UB. Simple case: https://gcc.godbolt.org/z/5E65rr95W Real world example: https://github.com/systemd/systemd/issues/22801 And the reason why is pretty simple: http://port70.net/~nsz/c/c11/n1570.html#7.22.3.4p2 > The malloc function allocates space for an object whose size is > specified by size and whose value is indeterminate.