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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_FONT_FACE_BAD,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2,T_KAM_HTML_FONT_INVALID autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29800 invoked from network); 19 Sep 2022 22:47:06 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 22:47:06 -0000 Received: (qmail 22052 invoked by uid 550); 19 Sep 2022 22:47:03 -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 22032 invoked from network); 19 Sep 2022 22:47:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:mime-version:references:subject:cc:to:from:date:from:to :cc:subject:date; bh=kxZ2LLxX/2Y4KKtRgYIaRnPbOcMvt629SA1XB+Re3w4=; b=Ylv6ZlpjVzhIv+f4ZwKslfKL52/xDQPEc5wxY94xDYRLw0zaEVyZJg9ffuT/NOWrHd zU0Jcd2RdXQ9LSALzZc6KmqdSKIvu3ZO1PYpGWLYseKqhFtnFHEp9Q4OJw62z1TMIW6o AD7gDxk6r3T0HSJFHWheTgbl4ZxYnvu6d4UBAIuWoEsMYXn9P7w7iKF7ypKQmqdPxHxA bp/QjA/nA07+Re++EcvnvvbWKi3oJVUsO4TX/Y7S2msyblFp19ccSkHKoeJKPCTfMI7C vGRqHd6wg0Gzn2Uzjw8jJVamna+Ov7pa9ZF1y3VaBOprx3CbLP4G5bKalCwBrx/KNyvZ Usjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:mime-version:references:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=kxZ2LLxX/2Y4KKtRgYIaRnPbOcMvt629SA1XB+Re3w4=; b=fNZPUqwU8ZdmL9pRCkJ8sPjwHifXbN8m5q9j7p+4uGl21kd0qL1mKO7NNJKHB35L1L r6nt99HnP6gJEtDAwThCY9fXizCcv1+Z+hbWzXUuPY4V2XtwNWcBkAB/VoYYc2QNhoEH 0eKd/vYl40e41hKJz5YJW2AjBRB9WdgAZ3l22f8YEyVa4IaCf3w+W/kX4IHyabsM5bJj VuB6oTMRca+zlxnUVjykFkJz9SKAdO/Pz85cOqu8JP/pbMljE5MjDaK9tyXzLELgtxYk YYOh0mFzUCNChLdOWt8lOma7yXgP+0XMGavl8XWpmmMlTHQ3CyEIzpzgAG9DwZRu9l+l 4G0Q== X-Gm-Message-State: ACrzQf3pYYOdI7Ja8nkHp3osEKJ6dtyEmhfhGhUjM8OffxGmI8yFWEOr erfPJAbJcWP/vctId515PQU= X-Google-Smtp-Source: AMsMyM4sPjqEshCV29KgOs0DFT+BPkS2Uoutc9c2U96lUuQgXdyEUv0xXB4n49+u/puCOr/7mSuCHg== X-Received: by 2002:a63:594c:0:b0:438:f2ce:8780 with SMTP id j12-20020a63594c000000b00438f2ce8780mr17550944pgm.285.1663627610098; Mon, 19 Sep 2022 15:46:50 -0700 (PDT) Date: Tue, 20 Sep 2022 06:46:52 +0800 From: baiyang To: "Gabriel Ravier" , "Rich Felker" Cc: "James Y Knight" , musl , "Florian Weimer" 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>, , <20220919192126.GV9709@brightrain.aerifal.cx>, <83f1e705-22b2-79b1-123c-1403d3e2281c@gmail.com>, <20220919214740.GA9709@brightrain.aerifal.cx>, <9738d1db-c50c-c46d-0c37-b6a6d16d956c@gmail.com> X-Priority: 3 X-GUID: 8493498C-AC97-4AD0-8E32-06C5A912C2FA X-Has-Attach: no X-Mailer: Foxmail 7.2.23.116[cn] Mime-Version: 1.0 Message-ID: <2022092006465015783579@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart086736467612_=----" Subject: Re: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) This is a multi-part message in MIME format. ------=_001_NextPart086736467612_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiBNeSBhcmd1bWVudGF0aW9uIHdhcyBlbnRpcmVseSBhZ2FpbnN0IHN0YXRpbmcgdGhhdCByZWx5 aW5nIG9uIG1hbGxvY191c2FibGVfc2l6ZSB0byBpbmRpY2F0ZSB0aGUgc2l6ZSBvZiBhbiBvYmpl Y3QgaXMgVUIgDQoNCkkgdG90YWxseSBhZ3JlZSB3aXRoIHRoaXMgcG9pbnQsIGluIGFsbCBrbm93 biBjYXNlcyB0aGUgZnVuY3Rpb24gd2hlcmUgdGhlIGVycm9yIG9jY3VycyBpcyBfX2J1aWx0aW5f ZHluYW1pY19vYmplY3Rfc2l6ZSwgbm90IG1hbGxvY191c2FibGVfc2l6ZS4NCg0KQXMgeW91IHJl ZmVyZW5jZWQgZWFybGllciBpbiB0aGUgYnVnemlsbGEgZGlzY3Vzc2lvbiAoaHR0cHM6Ly9zb3Vy Y2V3YXJlLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MjQ3NzUjYzYpOiBUaGlzIGlzIGEg YnVnIGluIE1zYW4uIE5PVCBpbiBtYWxsb2NfdXNhYmxlX3NpemUuDQoNClNvIGl0IHNlZW1zIHRv IG1lIGFuIG9kZCBjaG9pY2UgdG8gYWRkIHNpZ25pZmljYW50IG92ZXJoZWFkIHRvIGNhbGxzIGxp a2UgYG1hbGxvY191c2FibGVfc2l6ZWAsIGByZWFsbG9jYCwgYW5kIGBmcmVlYCBpbiBvcmRlciB0 byAiZml4IiB0aGlzIG5vbi1leGlzdGVudCBidWcuDQogDQotLQ0KDQogICBCZXN0IFJlZ2FyZHMN CiAgQmFpWWFuZw0KICBiYWl5YW5nQGdtYWlsLmNvbQ0KICBodHRwOi8vaS5iYWl5LmNuDQoqKioq IDwgRU5EIE9GIEVNQUlMID4gKioqKiANCiANCiANCkZyb206IEdhYnJpZWwgUmF2aWVyDQpEYXRl OiAyMDIyLTA5LTIwIDA2OjMxDQpUbzogUmljaCBGZWxrZXINCkNDOiBiYWl5YW5nOyBKYW1lcyBZ IEtuaWdodDsgbXVzbDsgRmxvcmlhbiBXZWltZXINClN1YmplY3Q6IFJlOiBbbXVzbF0gVGhlIGhl YXAgbWVtb3J5IHBlcmZvcm1hbmNlIChtYWxsb2MvZnJlZS9yZWFsbG9jKSBpcyBzaWduaWZpY2Fu dGx5IGRlZ3JhZGVkIGluIG11c2wgMS4yIChjb21wYXJlZCB0byAxLjEpDQpPbiA5LzE5LzIyIDIz OjQ3LCBSaWNoIEZlbGtlciB3cm90ZToNCj4gT24gTW9uLCBTZXAgMTksIDIwMjIgYXQgMTE6MDI6 MTZQTSArMDIwMCwgR2FicmllbCBSYXZpZXIgd3JvdGU6DQo+PiBPbiA5LzE5LzIyIDIxOjIxLCBS aWNoIEZlbGtlciB3cm90ZToNCj4+PiBPbiBNb24sIFNlcCAxOSwgMjAyMiBhdCAwOTowNzo1N1BN ICswMjAwLCBHYWJyaWVsIFJhdmllciB3cm90ZToNCj4+Pj4gT24gOS8xOS8yMiAyMDoxNCwgU3ph Ym9sY3MgTmFneSB3cm90ZToNCj4+Pj4+ICogYmFpeWFuZyA8YmFpeWFuZ0BnbWFpbC5jb20+IFsy MDIyLTA5LTIwIDAxOjQwOjQ4ICswODAwXToNCj4+Pj4+PiBJIGxvb2tlZCBhdCB0aGUgY29kZSBv ZiB0Y21hbGxvYywgYnV0IEkgZGlkbid0IGZpbmQgYW55IG9mIHRoZSBwcm9ibGVtcyB5b3UgbWVu dGlvbmVkIGluIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBtYWxsb2NfdXNhYmxlX3NpemUgKHNlZTog aHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS90Y21hbGxvYy9ibG9iLzkxNzliYjg4NDg0OGMzMDYx NjY2N2JhMTI5YmNmOWFmZWUxMTRjMzIvdGNtYWxsb2MvdGNtYWxsb2MuY2MjTDEwOTkgKS4NCj4+ Pj4+Pg0KPj4+Pj4+IE9uIHRoZSBjb250cmFyeSwgc2ltaWxhciB0byBtdXNsLCB0Y21hbGxvYyBh bHNvIGRpcmVjdGx5IHVzZXMgdGhlIHJldHVybiB2YWx1ZSBvZiBtYWxsb2NfdXNhYmxlX3NpemUg aW4gaXRzIHJlYWxsb2MgaW1wbGVtZW50YXRpb24gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgbWVtb3J5 IG5lZWRzIHRvIGJlIHJlYWxsb2NhdGVkOiBodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL3RjbWFs bG9jL2Jsb2IvOTE3OWJiODg0ODQ4YzMwNjE2NjY3YmExMjliY2Y5YWZlZTExNGMzMi90Y21hbGxv Yy90Y21hbGxvYy5jYyNMMTQ5OQ0KPj4+Pj4+DQo+Pj4+Pj4gSSB0aGluayB0aGlzIGlzIGVub3Vn aCB0byBzaG93IHRoYXQgdGhlIHJldHVybiB2YWx1ZSBvZiBtYWxsb2NfdXNhYmxlX3NpemUgaW4g dGNtYWxsb2MgaXMgYWNjdXJhdGUgYW5kIHJlbGlhYmxlLCBvdGhlcndpc2UgaXRzIG93biByZWFs bG9jIHdpbGwgY2F1c2UgYSBzZWdtZW50IGZhdWx0Lg0KPj4+Pj4gb2J2aW91c2x5IGludGVybmFs bHkgdGhlIGltcGxlbWVudGF0aW9uIGNhbiB1c2UgdGhlIGludGVybmFsIGNodW5rIHNpemUuLi4N Cj4+Pj4+DQo+Pj4+PiBHZXRTaXplKHApIGlzIG5vdCB0aGUgZXhhY3Qgc2l6ZSAodGhhdCB0aGUg dXNlciBhbGxvY2F0ZWQpIGJ1dCBhbiBpbnRlcm5hbA0KPj4+Pj4gc2l6ZSAod2hpY2ggbWF5IGJl IGxhcmdlcikgYW5kIHRoYXQgbXVzdCBub3QgYmUgZXhwb3NlZCAqb3V0c2lkZSogb2YgdGhlDQo+ Pj4+PiBtYWxsb2MgaW1wbGVtZW50YXRpb24gKG90aGVyIHRoYW4gZm9yIGRpYWdub3N0aWMgcHVy cG9zZXMpLg0KPj4+Pj4NCj4+Pj4+IHlvdSBjYW4gaGF2ZSAyIHZpZXdzOg0KPj4+Pj4NCj4+Pj4+ ICgxKSB0Y21hbGxvYyBhbmQgamVtYWxsb2MgYXJlIGJ1Z2d5IGJlY2F1c2UgdGhleSBleHBvc2Ug YW4gaW50ZXJuYWwNCj4+Pj4+ICAgICAgdGhhdCBtdXN0IG5vdCBiZSBleHBvc2VkIChiZWNhdWVz IGl0IGNhbiBicmVhayB1c2VyIGNvZGUpLg0KPj4+Pj4NCj4+Pj4+ICgyKSB1c2VyIGNvZGUgaXMg YnVnZ3kgaWYgaXQgdXNlcyBtYWxsb2NfdXNhYmxlX3NpemUgZm9yIGFueSBwdXJwb3NlDQo+Pj4+ PiAgICAgIG90aGVyIHRoYW4gZGlhZ25vc3RpYy9zdGF0aXN0aWNzIChiZWNhdXNlIG90aGVyIHVz ZXMgYXJlIGJyb2tlbg0KPj4+Pj4gICAgICBvbiBtYW55IGltcGxlbWVudGF0aW9ucykuDQo+Pj4+ Pg0KPj4+Pj4gZWl0aGVyIHdheSB0aGUgYnJva2VubmVzcyB5b3Ugd2FudCB0byBzdXBwb3J0IGlz IGEgc2VjdXJpdHkgaGF6YXJkDQo+Pj4+PiBhbmQgeW91IGFyZSBsdWNreSB0aGF0IG11c2wgc2F2 ZXMgdGhlIGRheTogaXQgd29ya3MgaGFyZCBub3QgdG8NCj4+Pj4+IGV4cG9zZSBpbnRlcm5hbCBz aXplcyBzbyB0aGUgY29kZSB5b3Ugc2VlbSB0byBjYXJlIGFib3V0IGNhbiBvcGVyYXRlDQo+Pj4+ PiBzYWZlbHkgKHdoaWNoIGlzIG5vdCB0cnVlIG9uIHRjbWFsbG9jIGFuZCBqZW1hbGxvYzogdGhl IGNvbXBpbGVyDQo+Pj4+PiBtYXkgYnJlYWsgdGhhdCBjb2RlKS4NCj4+Pj4gV2hpbGUgSSB3b3Vs ZCBhZ3JlZSB0aGF0IHVzaW5nIG1hbGxvY191c2FibGVfc2l6ZSBpcyBnZW5lcmFsbHkgbm90IGEN Cj4+Pj4gZ3JlYXQgaWRlYSAoaXQncyBhdCBtb3N0IGFjY2VwdGFibGUgYXMgYSBzbWFsbCBtaWNy by1vcHRpbWl6YXRpb24sDQo+Pj4+IGJ1dCBJIHdvdWxkIG9ubHkgZXZlciBleHBlY3QgaXQgdG8g YmUgc2VlbiBpbiB2ZXJ5IHdlbGwtdGVzdGVkIGNvZGUNCj4+Pj4gaW4gdmVyeSBob3QgbG9vcHMs IGFzIGl0IGlzIGluZGVlZCBxdWl0ZSBlYXNpbHkgbWlzdXNlZCksIGl0IHNlZW1zDQo+Pj4+IGxp a2UgYSBiaXQgb2YgYSBzdHJldGNoIHRvIHNheSB0aGF0IGFsbCBvZjoNCj4+Pj4NCj4+Pj4gLSBz cWxpdGUzIChodHRwczovL2dpdGh1Yi5jb20vc3FsaXRlL3NxbGl0ZS9ibG9iL21hc3Rlci9zcmMv bWVtMS5jKQ0KPj4+Pg0KPj4+PiAtIHN5c3RlbWQNCj4+Pj4gKGh0dHBzOi8vZ2l0aHViLmNvbS9z eXN0ZW1kL3N5c3RlbWQvYmxvYi9tYWluL3NyYy9iYXNpYy9hbGxvYy11dGlsLmgNCj4+Pj4gLCBh bG9uZyB3aXRoIGFsbCBmaWxlcyB1c2luZyBNQUxMT0NfU0laRU9GX1NBRkUsIGkuZS4NCj4+Pj4g c3JjL2Jhc2ljL2FsbG9jLXV0aWwuYywgc3JjL2Jhc2ljL2NvbXByZXNzLmMsIHNyYy9iYXNpYy9m aWxlaW8uYywNCj4+Pj4gc3JjL2Jhc2ljL21lbW9yeS11dGlsLmgsIHNyYy9iYXNpYy9yZWN1cnNl LWRpci5jLA0KPj4+PiBzcmMvYmFzaWMvc3RyaW5nLXV0aWwuYywgc3JjL2xpYnN5c3RlbWQvc2Qt bmV0bGluay9uZXRsaW5rLXNvY2tldC5jLA0KPj4+PiBzcmMvc2hhcmVkL2pvdXJuYWwtaW1wb3J0 ZXIuYywgc3JjL3NoYXJlZC92YXJsaW5rLmMsDQo+Pj4+IHNyYy90ZXN0L3Rlc3QtYWxsb2MtdXRp bC5jIGFuZCBzcmMvdGVzdC90ZXN0LWNvbXByZXNzLmMpDQo+Pj4+DQo+Pj4+IC0gcm9ja3NkYiAo aHR0cHM6Ly9naXRodWIuY29tL2ZhY2Vib29rL3JvY2tzZGIvYmxvYi9tYWluL3RhYmxlL2Jsb2Nr X2Jhc2VkL2ZpbHRlcl9wb2xpY3kuY2MNCj4+Pj4gLCBhbG9uZyB3aXRoIGF0IGxlYXN0IDIwIG90 aGVyIHVzZXMpDQo+Pj4+DQo+Pj4+IC0gZm9sbHkgKGh0dHBzOi8vZ2l0aHViLmNvbS9mYWNlYm9v ay9mb2xseS9ibG9iL21haW4vZm9sbHkvc21hbGxfdmVjdG9yLmgpDQo+Pj4+DQo+Pj4+IC0gbHpo YW1fY29kZWMgKGh0dHBzOi8vZ2l0aHViLmNvbS9yaWNoZ2VsOTk5L2x6aGFtX2NvZGVjL2Jsb2Iv bWFzdGVyL2x6aGFtZGVjb21wL2x6aGFtX21lbS5jcHApDQo+Pj4+DQo+Pj4+IC0gcXVpY2tqcw0K Pj4+PiAoaHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL2JlbGxhcmQvcXVpY2tqcy9t YXN0ZXIvcXVpY2tqcy5jKQ0KPj4+Pg0KPj4+PiAtIHJlZGlzDQo+Pj4+IChodHRwczovL2dpdGh1 Yi5jb20vcmVkaXMvcmVkaXMvYmxvYi91bnN0YWJsZS9zcmMvbmV0d29ya2luZy5jLA0KPj4+PiBh bG9uZyB3aXRoIGEgZmV3IG90aGVyIHVzZXMgZWxzZXdoZXJlKQ0KPj4+Pg0KPj4+PiBhbG9uZyB3 aXRoIHNvIG1hbnkgbW9yZSB3ZWxsLWtub3duIHByb2plY3RzIHRoYXQgSSd2ZSBnaXZlbiB1cCBv bg0KPj4+PiBsaXN0aW5nIHRoZW0sIGFyZSBhbGwgYnVnZ3kgYmVjYXVzZSBvZiB0aGVpciB1c2Fn ZSBvZg0KPj4+PiBtYWxsb2NfdXNhYmxlX3NpemUuLi4NCj4+PiBEZXBlbmRpbmcgb24gaG93IHlv dSBpbnRlcnByZXQgdGhlIGNvbnRyYWN0IG9mIG1hbGxvY191c2FibGVfc2l6ZQ0KPj4+ICh3aGlj aCB3YXMgaGlzdG9yaWNhbGx5IGFtYmlnaW91cyksIGVpdGhlciAoMSkgb3IgKDIpIGFib3ZlIGlz DQo+Pj4gKm5lY2Vzc2FyaWx5KiB0cnVlLiBJdCdzIG5vdCBhIG1hdHRlciBvZiBvcGluaW9uIGp1 c3QgbG9naWNhbA0KPj4+IGNvbnNlcXVlbmNlcyBvZiB0aGUgY2hvaWNlIHlvdSBtYWtlLg0KPj4g SG1tbW0uLi4gdG8gbWUgbm9uZSBvZiB0aGUgdHdvIG9wdGlvbnMgeW91IGhhdmUgZ2l2ZW4gYXJl IHRydWUuDQo+PiBJbnN0ZWFkLCBJJ2QgYXJndWUgdGhhdCwgYXMgc2VlbiBieSB0aGUgQyBhYnN0 cmFjdCBtYWNoaW5lLA0KPj4gaW52b2NhdGlvbiBvZiBtYWxsb2NfdXNhYmxlX3NpemUgYWN0dWFs bHkgaW5jcmVhc2VzIHRoZSBzaXplIG9mIGENCj4+IG1lbW9yeSBibG9jaywgaW4gcGxhY2UsIGFz IGlmIGJ5IG1hZ2ljLiBUaGlzIG1heSBzZWVtIHN0dXBpZCB0byBzb21lDQo+PiBkZWdyZWUsIGJ1 dCB0byBtZSBpdCBpcyB0aGUgb25seSB3YXkgb25lIGNhbiBtYWtlIHNlbnNlIG9mIHRoZQ0KPj4g ZG9jdW1lbnRhdGlvbiBmb3IgbWFsbG9jX3VzYWJsZV9zaXplIGluIGdsaWJjLCBhcyBpdCBoYXMg YmVlbg0KPj4gcHJlc2VudCBpbiBnbGliYyBzaW5jZSBtYWxsb2NfdXNhYmxlX3NpemUgd2FzIGZp cnN0IGFkZGVkIGluIDE5OTY6DQo+IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHN0dXBpZDsgaXQncyBh IHZlcnkgcmVhc29uYWJsZSBtb2RlbC4NCj4gVW5mb3J0dW5hdGVseSBpdCdzIG9uZSB0aGF0J3Mg dmVyeSBoYXJkIHRvIG1ha2UgdGhlIGNvbXBpbGVyIGF3YXJlIG9mLA0KPiBhbmQgaWYgdGhlIGNv bXBpbGVyIGNhbid0IGJlIGF3YXJlIG9mIHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgb2JqZWN0DQo+ IGNoYW5naW5nIHNpemUsIHRoZW4gaXQgbG9zZXMgdGhlIGFiaWxpdHkgdG8gcHJvdGVjdCB5b3Ug ZnJvbSBtZW1vcnkNCj4gZXJyb3JzIHdpdGhvdXQgaGF2aW5nIHRoaXMga2luZCBvZiAiZmFsc2Ug cG9zaXRpdmUiLg0KPg0KPiBOb3RlIHRoYXQgeW91IGNhbid0IGp1c3QgcmVhc29uIHRoYXQgIm1h bGxvY191c2FibGVfc2l6ZSBjb3VsZA0KPiBpbnRlcm5hbGx5IGhhdmUgY2FsbGVkIHJlYWxsb2Mi IGJlY2F1c2UgdGhlIGNvbXBpbGVyIGNhbiBzZWUgdGhhdCB0aGUNCj4gY2FsbGVyIGlzIHN0aWxs IHVzaW5nIHRoZSAib2xkIHBvaW50ZXIiLCB3aGljaCBpcyBpbnZhbGlkLCAqZXZlbiBpZg0KPiBy ZWFsbG9jIHJldHVybmVkIGEgYml0d2lzZS1pZGVudGljYWwgcG9pbnRlciogKGV2ZW4ganVzdCBj b21wYXJpbmcgdG8NCj4gc2VlIGlmIGl0J3MgZXF1YWwgaXMgVUIpLg0KPg0KPiBJIGRvbid0IGtu b3cgaG93IHRvIG1ha2UgYW55IG9mIHRoaXMgbm9uLWF3ZnVsLiBCYXNpY2FsbHksDQo+IG1hbGxv Y191c2FibGVfc2l6ZSB0aWVzIHlvdXIgaGFuZHMgd2l0aCBsb3RzIG9mIHVuZXhwZWN0ZWQNCj4g Y29uc3RyYWludHMuIFRoaXMgZnVuY3Rpb24gYWxvbmUgaXMgYWxtb3N0IHNvbGVseSByZXNwb25z aWJsZSBmb3IgdGhlDQo+IG11c2wgaW5jbHVzaW9uL2V4Y2x1c2lvbiBjcml0ZXJpYSBwb2xpY3kg Zm9yIG5vbnN0YW5kYXJkIGV4dGVuc2lvbnMNCj4gYmVpbmcgZXh0cmVtZWx5IGNhdXRpb3VzIGFi b3V0IGFkZGluZyBkdWJpb3VzIGV4dGVuc2lvbnMgZXZlbiBpZiB0aGV5DQo+ICJsb29rIGhhcm1s ZXNzIiBhdCBmaXJzdCAtLSB3ZSBtYWRlIHRoZSBtaXN0YWtlIG9mIGluY2x1ZGluZyBpdCBsb25n DQo+IGFnbywgYW5kIGRvbid0IHdhbnQgdG8gcmVwZWF0IHRoYXQuDQo+DQo+IFJpY2gNCiANCldl bGwsIHlvdSd2ZSBzYWlkIGVhcmxpZXIgdGhhdCB5b3VyIGltcGxlbWVudGF0aW9uIGtlZXBzIGlu IG1lbW9yeSB0aGUgDQpvcmlnaW5hbCByZXF1ZXN0ZWQgYW1vdW50IG9mIG1lbW9yeSBhbmQganVz dCByZXR1cm5zIHRoYXQsIGFuZCB0aGF0IA0KaW1wbGVtZW50YXRpb24gc2VlbXMgcGVyZmVjdGx5 IGZpbmU6IGl0IG1pZ2h0IGJlIGdvaW5nIHNsaWdodGx5IGFnYWluc3QgDQp0aGUgc3Bpcml0IG9m IHRoZSBvcmlnaW5hbCBmdW5jdGlvbiwgYnV0IGFzIHlvdSd2ZSBwb2ludGVkIG91dCwgaXQncyBh IA0KbmljZSB3YXkgb2YgYXZvaWRpbmcgdGhlIGF3ZnVsbmVzcyB0aGF0IG1hbGxvY191c2FibGVf c2l6ZSByZXN1bHRzIGluIA0Kdy5yLnQuIHRoZSB3b3JrIHRoZSBjb21waWxlciBoYXMgdG8gZG8g dG8gaGF2ZSBpdCB3b3JrIHByb3Blcmx5IHdoaWxlIA0Kbm90IHJ1aW5pbmcgb2JqZWN0IHNpemUg aW5zdHJ1bWVudGF0aW9uL29wdGltaXphdGlvbnMgKGFsdGhvdWdoIEkgDQpzdXBwb3NlIGl0IG1p Z2h0IGxlYWQgdG8gY3JpdGljaXNtcyBvZiBpdCB0YWtpbmcgdXAgdmFsdWFibGUgaGVhcCANCnNp emUvbWFraW5nIHByb2dyYW1zIHNsb3cgYnkgbmV1dHJhbGlzaW5nIEFQSXMgdXNlZCB0byBvcHRp bWl6ZSB0aGVtLCBhcyANCnNlZW4gaW4gdGhpcyB0aHJlYWQuLi4pDQogDQogDQpNeSBhcmd1bWVu dGF0aW9uIHdhcyBlbnRpcmVseSBhZ2FpbnN0IHN0YXRpbmcgdGhhdCByZWx5aW5nIG9uIA0KbWFs bG9jX3VzYWJsZV9zaXplIHRvIGluZGljYXRlIHRoZSBzaXplIG9mIGFuIG9iamVjdCBpcyBVQjog dG8gbWUsIGxpYmNzIA0KdGhhdCBjYW4ndCByZXR1cm4gYSB2YWxpZCByZXN1bHQgZm9yIGl0IHNo b3VsZCBub3QgcHJldGVuZCB0aGV5IHN1cHBvcnQgDQppdCBwcm9wZXJseSwgYW5kIGNvbXBpbGVy cyB0aGF0IG1ha2Ugb3B0aW1pemF0aW9ucyB0aGF0IG1ha2UgaXQgbm90IHdvcmsgDQp3aGVuIGl0 IHJldHVybnMgYSBoaWdoZXIgc2l6ZSB0aGFuIHRoZSBvcmlnaW5hbGx5IGFza2VkLWZvciBzaXpl IHNob3VsZCANCm5vdCBwcmV0ZW5kIHRoZXkgc3VwcG9ydCBpdCBwcm9wZXJseSBlaXRoZXIuIEdD QyB3aXRoIF9GT1JUSUZZX1NPVVJDRSANCmNvdXBsZWQgd2l0aCBnbGliYyBzZWVtcyB0byBleHBv c2UgdGhpcyBpc3N1ZSwgYW5kIHRoZXkgYmFzaWNhbGx5IG5lZWQgDQp0byBlaXRoZXI6DQogDQot IGhhdmUgR0NDIHByb3Blcmx5IHRha2UgbWFsbG9jX3VzYWJsZV9zaXplIGludG8gYWNjb3VudCB3 LnIudC4gdGhlaXIgDQpfX2J1aWx0aW5fZHluYW1pY19vYmplY3Rfc2l6ZSwgd2hpY2ggbWlnaHQg anVzdCBiZSBhIGNvbXBsZXRlIG5pZ2h0bWFyZSANCnRvIGltcGxlbWVudC4uLg0KIA0KLSBoYXZl IGdsaWJjIHdhcm4gdXBvbiBpdHMgdXNhZ2Ugd2l0aCBfRk9SVElGWV9TT1VSQ0UsIHdoaWNoIG1p Z2h0IGVuZCANCnVwIHdpdGggcGVvcGxlIGNvbXBsYWluaW5nIGFib3V0IF9GT1JUSUZZX1NPVVJD RSBicmVha2luZyB0aGVpciBwcm9ncmFtcyANCmFuZCBkaXNhYmxpbmcgdXNlZnVsIEFQSXMuLi4N CiANCi0gc3RhcnQgdGhlIGxvbmcgcHJvY2VzcyBvZiBkZXByZWNhdGluZyB0aGUgZnVuY3Rpb24g b3V0IG9mIGdsaWJjIA0KZW50aXJlbHksIHdoaWNoIG1pZ2h0IGVuZCB1cCB3aXRoIHBlb3BsZSBj b21wbGFpbmluZyBhYm91dCBnbGliYyBtYWtpbmcgDQp0aGVpciBwcm9ncmFtcyBsZXNzIGZhc3Qg YnkgZGlzYWJsaW5nIEFQSXMgdGhleSB1c2UgdG8gZG8gc28uLi4NCiANCi0gb3IgY2hhbmdlIHRo ZWlyIGhlYXAgaW1wbGVtZW50YXRpb24gc28gdGhleSBjYW4gcmV0dXJuIHRoZSBvcmlnaW5hbGx5 IA0KcmVxdWVzdGVkIHNpemUsIHdoaWNoIG1pZ2h0IGVuZCB1cCB3aXRoIHBlb3BsZSBjb21wbGFp bmluZyBhYm91dCBnbGliYyANCm1ha2luZyB0aGVpciBwcm9ncmFtcyB0YWtlIG1vcmUgaGVhcCBz cGFjZSBhbmQgc2xvd2VyIGJ5IHJldHVybmluZyBhIA0KInVzZWxlc3MiIHZhbHVlIG91dCBvZiBt YWxsb2NfdXNhYmxlX3NpemUgKHcuci50LiBzcGVlZCBvcHRpbWlzYXRpb25zKS4uLg0KIA0KUXVp dGUgdGhlIHBvdGVudGlhbGx5IGF3ZnVsIGNob2ljZSB0byBtYWtlIGluZGVlZC4uLg0KIA0KIA0K ------=_001_NextPart086736467612_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
> My argumentation was entirely = against stating that relying on malloc_usable_size to indicate the size of an object is UB <= /div>=0A

=
I totally agree= with this point, in all known cases the function where the error occurs i= s __builtin_dynamic_object_size, not malloc_us= able_size.

<= /span>
As you referenced earlier in t= he bugzilla discussion (https://sourceware.org/bugzilla/show_bug.cgi?id=3D= 24775#c6): This is a bug in Msan. NOT in malloc_usable_size.=

So it seems to me an odd choice to add significant = overhead to calls like `malloc_usable_size`, `realloc`, and `free` in orde= r to "fix" this non-existent bug.
 
=0A
--**** < END OF EMAIL > ****  
&= nbsp;
Date: 202= 2-09-20 06:31
Subject:&nbs= p;Re: [musl] The heap memory performance (malloc/free/realloc) is signific= antly degraded in musl 1.2 (compared to 1.1)
On= 9/19/22 23:47, Rich Felker wrote:
=0A
> On Mon, Sep 19, 2022 = at 11:02:16PM +0200, Gabriel Ravier wrote:
=0A
>> On 9/19/2= 2 21:21, Rich Felker wrote:
=0A
>>> On Mon, Sep 19, 2022= at 09:07:57PM +0200, Gabriel Ravier wrote:
=0A
>>>> = On 9/19/22 20:14, Szabolcs Nagy wrote:
=0A
>>>>> *= baiyang <baiyang@gmail.com> [2022-09-20 01:40:48 +0800]:
=0A>>>>>> I looked at the code of tcmalloc, but I didn't= find any of the problems you mentioned in the implementation of malloc_us= able_size (see: https://github.com/google/tcmalloc/blob/9179bb884848c30616= 667ba129bcf9afee114c32/tcmalloc/tcmalloc.cc#L1099 ).
=0A
>>= >>>>
=0A
>>>>>> On the contrary, si= milar to musl, tcmalloc also directly uses the return value of malloc_usab= le_size in its realloc implementation to determine whether memory needs to= be reallocated: https://github.com/google/tcmalloc/blob/9179bb884848c3061= 6667ba129bcf9afee114c32/tcmalloc/tcmalloc.cc#L1499
=0A
>>&g= t;>>>
=0A
>>>>>> I think this is enoug= h to show that the return value of malloc_usable_size in tcmalloc is accur= ate and reliable, otherwise its own realloc will cause a segment fault.=0A
>>>>> obviously internally the implementation ca= n use the internal chunk size...
=0A
>>>>>
= =0A
>>>>> GetSize(p) is not the exact size (that the us= er allocated) but an internal
=0A
>>>>> size (whic= h may be larger) and that must not be exposed *outside* of the
=0A>>>>> malloc implementation (other than for diagnostic pu= rposes).
=0A
>>>>>
=0A
>>>>&g= t; you can have 2 views:
=0A
>>>>>
=0A
&g= t;>>>> (1) tcmalloc and jemalloc are buggy because they expose= an internal
=0A
>>>>>    &nbs= p; that must not be exposed (becaues it can break user code).
=0A>>>>>=0A
>>>>> (2) user code is b= uggy if it uses malloc_usable_size for any purpose
=0A
>>&g= t;>>      other than diagnostic/statistics = (because other uses are broken
=0A
>>>>> &nbs= p;    on many implementations).
=0A
>>>&g= t;>
=0A
>>>>> either way the brokenness you wan= t to support is a security hazard
=0A
>>>>> and yo= u are lucky that musl saves the day: it works hard not to
=0A
>= ;>>>> expose internal sizes so the code you seem to care about= can operate
=0A
>>>>> safely (which is not true o= n tcmalloc and jemalloc: the compiler
=0A
>>>>> ma= y break that code).
=0A
>>>> While I would agree that= using malloc_usable_size is generally not a
=0A
>>>>= great idea (it's at most acceptable as a small micro-optimization,
= =0A
>>>> but I would only ever expect it to be seen in ver= y well-tested code
=0A
>>>> in very hot loops, as it = is indeed quite easily misused), it seems
=0A
>>>> li= ke a bit of a stretch to say that all of:
=0A
>>>>=0A
>>>> - sqlite3 (https://github.com/sqlite/sqlite/bl= ob/master/src/mem1.c)
=0A
>>>>
=0A
>>&= gt;> - systemd
=0A
>>>> (https://github.com/system= d/systemd/blob/main/src/basic/alloc-util.h
=0A
>>>> ,= along with all files using MALLOC_SIZEOF_SAFE, i.e.
=0A
>>= >> src/basic/alloc-util.c, src/basic/compress.c, src/basic/fileio.c,=
=0A
>>>> src/basic/memory-util.h, src/basic/recurse-= dir.c,
=0A
>>>> src/basic/string-util.c, src/libsyste= md/sd-netlink/netlink-socket.c,
=0A
>>>> src/shared/j= ournal-importer.c, src/shared/varlink.c,
=0A
>>>> src= /test/test-alloc-util.c and src/test/test-compress.c)
=0A
>>= ;>>
=0A
>>>> - rocksdb (https://github.com/face= book/rocksdb/blob/main/table/block_based/filter_policy.cc
=0A
>= ;>>> , along with at least 20 other uses)
=0A
>>&g= t;>
=0A
>>>> - folly (https://github.com/facebook/= folly/blob/main/folly/small_vector.h)
=0A
>>>>
= =0A
>>>> - lzham_codec (https://github.com/richgel999/lzha= m_codec/blob/master/lzhamdecomp/lzham_mem.cpp)
=0A
>>>&g= t;
=0A
>>>> - quickjs
=0A
>>>> (= https://raw.githubusercontent.com/bellard/quickjs/master/quickjs.c)
= =0A
>>>>
=0A
>>>> - redis
=0A>>>> (https://github.com/redis/redis/blob/unstable/src/netwo= rking.c,
=0A
>>>> along with a few other uses elsewhe= re)
=0A
>>>>
=0A
>>>> along with= so many more well-known projects that I've given up on
=0A
>&= gt;>> listing them, are all buggy because of their usage of
=0A=
>>>> malloc_usable_size...
=0A
>>> Depe= nding on how you interpret the contract of malloc_usable_size
=0A>>> (which was historically ambigious), either (1) or (2) above = is=0A
>>> *necessarily* true. It's not a matter of opin= ion just logical
=0A
>>> consequences of the choice you = make.
=0A
>> Hmmmm... to me none of the two options you hav= e given are true.
=0A
>> Instead, I'd argue that, as seen b= y the C abstract machine,
=0A
>> invocation of malloc_usabl= e_size actually increases the size of a
=0A
>> memory block= , in place, as if by magic. This may seem stupid to some
=0A
>= > degree, but to me it is the only way one can make sense of the
= =0A
>> documentation for malloc_usable_size in glibc, as it has = been
=0A
>> present in glibc since malloc_usable_size was f= irst added in 1996:
=0A
> I don't think that's stupid; it's a = very reasonable model.
=0A
> Unfortunately it's one that's ver= y hard to make the compiler aware of,
=0A
> and if the compile= r can't be aware of the possibility of the object
=0A
> changi= ng size, then it loses the ability to protect you from memory
=0A> errors without having this kind of "false positive".=0A
&g= t;
=0A
> Note that you can't just reason that "malloc_usable_s= ize could
=0A
> internally have called realloc" because the co= mpiler can see that the
=0A
> caller is still using the "old p= ointer", which is invalid, *even if
=0A
> realloc returned a b= itwise-identical pointer* (even just comparing to
=0A
> see if= it's equal is UB).
=0A
>
=0A
> I don't know how t= o make any of this non-awful. Basically,
=0A
> malloc_usable_s= ize ties your hands with lots of unexpected
=0A
> constraints.= This function alone is almost solely responsible for the
=0A
>= ; musl inclusion/exclusion criteria policy for nonstandard extensions=0A
> being extremely cautious about adding dubious extensions eve= n if they
=0A
> "look harmless" at first -- we made the mistak= e of including it long
=0A
> ago, and don't want to repeat tha= t.
=0A
>
=0A
> Rich
=0A
 
=0AWell, you've said earlier that your implementation keeps in memory the =
=0A
original requested amount of memory and just returns that, a= nd that
=0A
implementation seems perfectly fine: it might be goi= ng slightly against
=0A
the spirit of the original function, but= as you've pointed out, it's a
=0A
nice way of avoiding the awfu= lness that malloc_usable_size results in
=0A
w.r.t. the work the= compiler has to do to have it work properly while
=0A
not ruini= ng object size instrumentation/optimizations (although I
=0A
sup= pose it might lead to criticisms of it taking up valuable heap
=0Asize/making programs slow by neutralising APIs used to optimize them, a= s =0A
seen in this thread...)
=0A
 
=0A
&= nbsp;
=0A
My argumentation was entirely against stating that rely= ing on
=0A
malloc_usable_size to indicate the size of an object = is UB: to me, libcs
=0A
that can't return a valid result for it = should not pretend they support
=0A
it properly, and compilers t= hat make optimizations that make it not work
=0A
when it returns= a higher size than the originally asked-for size should
=0A
not= pretend they support it properly either. GCC with _FORTIFY_SOURCE
= =0A
coupled with glibc seems to expose this issue, and they basically = need
=0A
to either:
=0A
 
=0A
- have GCC = properly take malloc_usable_size into account w.r.t. their
=0A
_= _builtin_dynamic_object_size, which might just be a complete nightmare =0A
to implement...
=0A
 
=0A
- have glibc w= arn upon its usage with _FORTIFY_SOURCE, which might end
=0A
up = with people complaining about _FORTIFY_SOURCE breaking their programs =0A
and disabling useful APIs...
=0A
 
=0A
- = start the long process of deprecating the function out of glibc
=0A<= div>entirely, which might end up with people complaining about glibc makin= g
=0A
their programs less fast by disabling APIs they use to do = so...
=0A
 
=0A
- or change their heap implementati= on so they can return the originally
=0A
requested size, which m= ight end up with people complaining about glibc
=0A
making their= programs take more heap space and slower by returning a
=0A
"us= eless" value out of malloc_usable_size (w.r.t. speed optimisations)...=0A
 
=0A
Quite the potentially awful choice to make i= ndeed...
=0A
 
=0A
 
=0A
=0A ------=_001_NextPart086736467612_=------

   Best Regards
  BaiYang
  = ;baiyang@gmail.com
  = ;http://i.baiy.cn