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.5 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16338 invoked from network); 19 Sep 2022 20:48:50 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 20:48:50 -0000 Received: (qmail 17708 invoked by uid 550); 19 Sep 2022 20:48:48 -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 15946 invoked from network); 19 Sep 2022 20:46:32 -0000 Message-ID: <8cf054ed-aed1-5371-2353-2d4059f88cfd@mulle-kybernetik.com> Date: Mon, 19 Sep 2022 22:46:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-US To: musl@lists.openwall.com References: <2022091915532777412615@gmail.com> <20220919110829.GA2158779@port70.net> <874jx3h76u.fsf@oldenburg.str.redhat.com> <20220919134659.GO9709@brightrain.aerifal.cx> <2022092001404698842815@gmail.com> <20220919181441.GC2158779@port70.net> From: Nat! In-Reply-To: <20220919181441.GC2158779@port70.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) On 19.09.22 20:14, Szabolcs Nagy wrote: > * baiyang [2022-09-20 01:40:48 +0800]: >> I looked at the code of tcmalloc, but I didn't find any of the problems you mentioned in the implementation of malloc_usable_size (see: https://github.com/google/tcmalloc/blob/9179bb884848c30616667ba129bcf9afee114c32/tcmalloc/tcmalloc.cc#L1099 ). >> >> On the contrary, similar to musl, tcmalloc also directly uses the return value of malloc_usable_size in its realloc implementation to determine whether memory needs to be reallocated: https://github.com/google/tcmalloc/blob/9179bb884848c30616667ba129bcf9afee114c32/tcmalloc/tcmalloc.cc#L1499 >> >> I think this is enough to show that the return value of malloc_usable_size in tcmalloc is accurate and reliable, otherwise its own realloc will cause a segment fault. > obviously internally the implementation can use the internal chunk size... > > GetSize(p) is not the exact size (that the user allocated) but an internal > size (which may be larger) and that must not be exposed *outside* of the > malloc implementation (other than for diagnostic purposes). > > you can have 2 views: > > (1) tcmalloc and jemalloc are buggy because they expose an internal > that must not be exposed (becaues it can break user code). > > (2) user code is buggy if it uses malloc_usable_size for any purpose > other than diagnostic/statistics (because other uses are broken > on many implementations). > > either way the brokenness you want to support is a security hazard > and you are lucky that musl saves the day: it works hard not to > expose internal sizes so the code you seem to care about can operate > safely (which is not true on tcmalloc and jemalloc: the compiler > may break that code). > You can also have the third view, that malloc is allocating "at least" the amount of size requested (as it technically it is likely to do). That you can use "malloc_usable_size" to get the actually available size. That the code that is enforcing the semantics, that only the "at least" bytes should be accessed is in error, unless the error checking code modifies "malloc_usable_size" to only return the size as requested by the user. Surely not a popular opinion :D :D Ciao    Nat!