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 14559 invoked from network); 19 Sep 2022 20:33:33 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 20:33:33 -0000 Received: (qmail 6117 invoked by uid 550); 19 Sep 2022 20:33:31 -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 6074 invoked from network); 19 Sep 2022 20:33:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:mime-version:references:subject:to:from:date:from:to:cc :subject:date; bh=G6HORYmnKzE2DfSpeZBTGsO42N+0E1cApYsVdTeW62Y=; b=P/sTUnlZN3Trsc8kayXTQSc8C//2mlhW6VNhQ1Gjkih5h8JIteBennUH8fFSw08XBs 3j2kd5xNjKl9no+Xh/OkKar3TVqzC9ZHnvGKSomFejSfuzB4dxlRt1+aImdZZOLJDXER sxfQW1OMwhYx1giYRg8wyxyWnN2RL263/cD4H4jmyPC+NwS8zvMuJadoULb49FNO5ntk ZtVPQVmE+rhtdH/kLv2toMqe4wD4Cpu6wUwZ/M4uVmF556BIOaea/jC+fEoJ5GK2fl+W eXe90eGdEdGdFcJpbByPXXxfm5K7FChkqTEbmsHq6/YGtrKeRd1Cv3kSRbM+e5jAWhZL oTpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:mime-version:references:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=G6HORYmnKzE2DfSpeZBTGsO42N+0E1cApYsVdTeW62Y=; b=Wd4IJYlvWNly7kK+tDCucqeHlURidFfSJylWmB1IvKMOCbwkfqm1UfNA9NVD4Zv8+p W4pJNIJwrOkRml9wnEAzmOJfZF/8EPyygibDEVPfPjMIlBocqdTNmh7s/4o1oCmAiEYb 2hp/EG8PO1YHBtOFCLn+W88vtQTq9QsI8q0qUYto6AE4kYNQ3FiIOyQn+6UYsLUnjXxB xTEGt2sZEagXa6VGtiPpD43nlLpW6nhhCwAVGV+WyW9UmdCu5aoIldwvum3l9gkryVaC DKF1VRBtm5q6Fa2zrk7Fo0OWwkK9HGdd/6bf+Q29rY8rOPsITfLv3i4zRlVISJmgKJp8 cWqw== X-Gm-Message-State: ACrzQf28MnrK9YezFdgdLojk/ECqO3XsaROCRG1KzMDQeWYIb6eKuphd TafrBOxqrJLRd6XR658acbfZ45Bq3AB06w== X-Google-Smtp-Source: AMsMyM4Pi2u/VGto3y2DaI72uTo+oWQQHYnqlDtke7wbnH8hIZLzaFUQemG3YG94YILyApKV9fNYaw== X-Received: by 2002:a17:902:eccb:b0:178:1313:afa1 with SMTP id a11-20020a170902eccb00b001781313afa1mr1473205plh.97.1663619597736; Mon, 19 Sep 2022 13:33:17 -0700 (PDT) Date: Tue, 20 Sep 2022 04:33:20 +0800 From: baiyang To: musl 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>, <20220919221702.2c8da85cc0638c2fdf43ac6a@zhasha.com> X-Priority: 3 X-GUID: 39A7AF21-ED8B-4180-860D-79EF497CEE5D X-Has-Attach: no X-Mailer: Foxmail 7.2.23.116[cn] Mime-Version: 1.0 Message-ID: <2022092004331912203464@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart467646415737_=----" 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_NextPart467646415737_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiB5b3Ugd2lsbCBoaXQgVUINClRoYW5rcyBmb3IgdGhlIGluZm9ybWF0aW9uLCBidXQ6DQoxLiBB cyB3ZSBoYXZlIGRpc2N1c3NlZCBpbiBvdGhlciBlbWFpbHMsIHdlIGRvIG5vdCB1c2UgbWFsbG9j X3VzYWdlX3NpemUgYXMgc3VjaC4NCjIuIFRoaXMgaXMgbW9zdCBsaWtlbHkgYSBwcm9ibGVtIHdp dGggZ2NjJ3MgY29ycmVzcG9uZGluZyBjaGVja2luZyBtZWNoYW5pc20sIHJhdGhlciB0aGFuIHVz aW5nIGdsaWJjJ3MgbWFsbG9jX3VzYWJsZV9zaXplKCkgaW4gdGhpcyB3YXksIHNlZTogaHR0cHM6 Ly9nY2MuZ29kYm9sdC5vcmcvei9xaHFoZVRxY3oNCiANCi0tDQoNCiAgIEJlc3QgUmVnYXJkcw0K ICBCYWlZYW5nDQogIGJhaXlhbmdAZ21haWwuY29tDQogIGh0dHA6Ly9pLmJhaXkuY24NCioqKiog PCBFTkQgT0YgRU1BSUwgPiAqKioqIA0KIA0KIA0KRnJvbTogSm9ha2ltIFNpbmRob2x0DQpEYXRl OiAyMDIyLTA5LTIwIDA0OjE3DQpUbzogbXVzbA0KU3ViamVjdDogUmU6IFttdXNsXSBUaGUgaGVh cCBtZW1vcnkgcGVyZm9ybWFuY2UgKG1hbGxvYy9mcmVlL3JlYWxsb2MpIGlzIHNpZ25pZmljYW50 bHkgZGVncmFkZWQgaW4gbXVzbCAxLjIgKGNvbXBhcmVkIHRvIDEuMSkNCk9uIFR1ZSwgMjAgU2Vw IDIwMjIgMDM6NDU6MzUgKzA4MDAsIGJhaXlhbmcgPGJhaXlhbmdAZ21haWwuY29tPiB3cm90ZToN Cj4gPiBUaGUgb25seSBjb3JyZWN0IHZhbHVlIG1hbGxvY191c2FibGVfc2l6ZSBjYW4gcmV0dXJu IGlzIHRoZSB2YWx1ZSB5b3UgcGFzc2VkIHRvIHRoZSBhbGxvY2F0b3IuIA0KPiANCj4gSSBkb24n dCB0aGluayBzbywgc2VlOg0KPiANCj4gTGludXggbWFuIHBhZ2U6IGh0dHBzOi8vbWFuNy5vcmcv bGludXgvbWFuLXBhZ2VzL21hbjMvbWFsbG9jX3VzYWJsZV9zaXplLjMuaHRtbCAtICJUaGUgdmFs dWUgcmV0dXJuZWQgYnkgbWFsbG9jX3VzYWJsZV9zaXplKCkgbWF5IGJlICoqZ3JlYXRlciB0aGFu KiogdGhlIHJlcXVlc3RlZCBzaXplIG9mIHRoZSBhbGxvY2F0aW9uIi4NCj4gDQo+IE1hYyBPUyBY IG1hbiBwYWdlOiBodHRwczovL2RldmVsb3Blci5hcHBsZS5jb20vbGlicmFyeS9hcmNoaXZlL2Rv Y3VtZW50YXRpb24vU3lzdGVtL0NvbmNlcHR1YWwvTWFuUGFnZXNfaVBob25lT1MvbWFuMy9tYWxs b2Nfc2l6ZS4zLmh0bWwgLSAiVGhlIG1lbW9yeSBibG9jayBzaXplIGlzIGFsd2F5cyBhdCBsZWFz dCBhcyBsYXJnZSBhcyB0aGUgYWxsb2NhdGlvbiBpdCBiYWNrcywgKiphbmQgbWF5IGJlIGxhcmdl cioqLiINCj4gDQo+IEZyZWVCU0QgbWFuIHBhZ2U6IGh0dHBzOi8vd3d3LmZyZWVic2Qub3JnL2Nn aS9tYW4uY2dpP3F1ZXJ5PW1hbGxvY191c2FibGVfc2l6ZSZhcHJvcG9zPTAmc2VrdGlvbj0wJm1h bnBhdGg9RnJlZUJTRCs3LjEtUkVMRUFTRSZmb3JtYXQ9aHRtbCAtICJUaGUgcmV0dXJuIHZhbHVl ICoqbWF5IGJlIGxhcmdlcioqIHRoYW4gdGhlIHNpemUgdGhhdCB3YXMgcmVxdWVzdGVkIGR1cmlu ZyBhbGxvY2F0aW9uIi4NCj4gDQo+IFRoZXNlIG9mZmljaWFsIG1hbiBwYWdlcyBjbGVhcmx5IHN0 YXRlIHRoYXQgdGhlIHJldHVybiB2YWx1ZSBvZiBtYWxsb2NfdXNhYmxlX3NpemUgaXMgdGhlIHNp emUgb2YgdGhlIG1lbW9yeSBibG9jayBhbGxvY2F0ZWQgaW50ZXJuYWxseSwgbm90IHRoZSBzaXpl IHN1Ym1pdHRlZCBieSB0aGUgdXNlci4gDQo+IA0KPiBJbnN0ZWFkLCB3ZSBkaWRuJ3QgZmluZCBh bnkgZG9jdW1lbnRhdGlvbiBzYXlpbmcgdGhhdCB0aGUgcmV0dXJuIHZhbHVlIG9mIG1hbGxvY191 c2FibGVfc2l6ZSBtdXN0IGJlIHRoZSBzaXplIHN1Ym1pdHRlZCBieSB0aGUgdXNlciB0byBiZSBj b3JyZWN0LiBQbGVhc2UgY29ycmVjdCBtZSBpZiB5b3UgaGF2ZSB0aGUgcmVsZXZhbnQgZG9jdW1l bnRhdGlvbi4NCiANCkl0J3Mgbm90IHRoYXQgbWFsbG9jX3VzYWJsZV9zaXplIG11c3QgcmV0dXJu IHRoZSBzaXplIG9yaWdpbmFsbHkNCnN1Ym1pdHRlZCBieSB0aGUgdXNlciBidXQgdGhhdCBpZiBp dCBkb2Vzbid0IGFuZCB5b3UgdGFrZSB0aGF0IGFzIGFuDQppbnZpdGF0aW9uIHRvIGV4Y2VlZCB0 aGUgb3JpZ2luYWwgc2l6ZSBhbGxvY2F0ZWQgeW91IHdpbGwgaGl0IFVCLg0KIA0KU2ltcGxlIGNh c2U6DQpodHRwczovL2djYy5nb2Rib2x0Lm9yZy96LzVFNjVycjk1Vw0KUmVhbCB3b3JsZCBleGFt cGxlOg0KaHR0cHM6Ly9naXRodWIuY29tL3N5c3RlbWQvc3lzdGVtZC9pc3N1ZXMvMjI4MDENCiAN CkFuZCB0aGUgcmVhc29uIHdoeSBpcyBwcmV0dHkgc2ltcGxlOg0KaHR0cDovL3BvcnQ3MC5uZXQv fm5zei9jL2MxMS9uMTU3MC5odG1sIzcuMjIuMy40cDINCj4gVGhlIG1hbGxvYyBmdW5jdGlvbiBh bGxvY2F0ZXMgc3BhY2UgZm9yIGFuIG9iamVjdCB3aG9zZSBzaXplIGlzDQo+IHNwZWNpZmllZCBi eSBzaXplIGFuZCB3aG9zZSB2YWx1ZSBpcyBpbmRldGVybWluYXRlLg0K ------=_001_NextPart467646415737_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
> you will hit UB
Thanks for the informatio= n, but:
1. As we have discussed in other emails, we do not use malloc_usage_s= ize as such.
2. <= font face=3D"=E6=96=B0=E5=AE=8B=E4=BD=93">This is most likely a problem wi= th gcc's corresponding checking mechanism, rather than using glibc's mallo= c_usable_size() in this way, see: https://gcc.godbolt.org/z/qhq= heTqcz
&nb= sp;
=0A
--

   Be= st Regards
  BaiYang
  baiyang@gmail.com
  h= ttp://i.baiy.cn
**** < END OF EMAIL > **** 
 
 
Date: 2022-09-20 04:17
To: musl
=
Subject: Re: [musl] The heap memory performance (malloc/f= ree/realloc) is significantly degraded in musl 1.2 (compared to 1.1)
=
On Tue, 20 Sep 2022 03:45:35 +0800, baiyang <baiy= ang@gmail.com> wrote:
=0A
> > The only correct value mal= loc_usable_size can return is the value you passed to the allocator. =0A
>
=0A
> I don't think so, see:
=0A
> =
=0A
> Linux man page: https://man7.org/linux/man-pages/man3/m= alloc_usable_size.3.html - "The value returned by malloc_usable_size() may= be **greater than** the requested size of the allocation".
=0A
&= gt;
=0A
> Mac OS X man page: https://developer.apple.com/libr= ary/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/malloc_= size.3.html - "The memory block size is always at least as large as the al= location it backs, **and may be larger**."
=0A
>
=0A> FreeBSD man page: https://www.freebsd.org/cgi/man.cgi?query=3Dmalloc= _usable_size&apropos=3D0&sektion=3D0&manpath=3DFreeBSD+7.1-REL= EASE&format=3Dhtml - "The return value **may be larger** than the size= that was requested during allocation".
=0A
>
=0A
&g= t; 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.
=0A
>
=0A
> Instead,= we didn't find any documentation saying that the return value of malloc_u= sable_size must be the size submitted by the user to be correct. Please co= rrect me if you have the relevant documentation.
=0A
 
= =0A
It's not that malloc_usable_size must return the size originally=0A
submitted by the user but that if it doesn't and you take that= as an
=0A
invitation to exceed the original size allocated you w= ill hit UB.
=0A
 
=0A
Simple case:
=0A
htt= ps://gcc.godbolt.org/z/5E65rr95W
=0A
Real world example:
=0A=
https://github.com/systemd/systemd/issues/22801
=0A
 =0A
And the reason why is pretty simple:
=0A
http://port7= 0.net/~nsz/c/c11/n1570.html#7.22.3.4p2
=0A
> The malloc functi= on allocates space for an object whose size is
=0A
> specified= by size and whose value is indeterminate.
=0A
=0A<= /body> ------=_001_NextPart467646415737_=------