From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 9070E3858D20 for ; Wed, 5 Apr 2023 21:00:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9070E3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-x436.google.com with SMTP id h17so37462262wrt.8 for ; Wed, 05 Apr 2023 14:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680728428; x=1683320428; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=9GlMgSTyDQ5u94pzZ75/ZY7Mtx9R0rDql7XT5lnmVis=; b=AkpW/vHgO88mkTH4djScucKdyhCQVKf9ibvBcROIAGVRX0xgcAKrdcV465UVje69hr iw2eIW2Xgpd4HlOB5C/HfvqYa+Z2rgfVKEKREhw1SKQdxo/BbIzW8pGnD4PXm1bt7L0M VLfvlO2ScLu1bn4ipIRRvUaJBg05F9YO+fkyYCaCy05q3TILMD9vtlozB3imNU2ekIOS c0F2bmePK7H7lUcNDtgcApHAS6sIUJMHh6ukVMuFEtX+SeKcCyefD3zgd/5QAb664TuX 06b4OEXJjeoEZhv1LkIow4wv0o0NYLGBz6KtRKfaZJ+5Jc5hhsxYZ3sE92OrLYw8yphJ X7+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680728428; x=1683320428; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=9GlMgSTyDQ5u94pzZ75/ZY7Mtx9R0rDql7XT5lnmVis=; b=J1nya0qMVl74tsg3DmOcxOWrd1KYeOvuzunB7qIGzM4bqQAOy31WWcgFGAevN5Jn3h 8jmyiGjVQQxp4CCp5lT4P7Qq2gwJfKbIOVzRdSDnBR1A+ScxBEU8tRt8cmsEcwDItohC Xe0mLIO9aIUWV6GkcueeZiqdbhobrMMXipCgZqwXzC8TSCtqPlOACegCT5P/p3wxjRT5 aQb0gSkhlJ5NR/IvRkDrbXMId1x62hYf8qrVCNYoDOsrPSe9wnkXaJBO/FDec6utCzy2 nSS747+x/gkLetxE2I1dmAGJFxXly6Rq1RRBNu19pRlp+FsZqWABrVRzVhSthvIz+1ZI mPfw== X-Gm-Message-State: AAQBX9d3zDpsEXBZQt43FmcWXcXYOW7oJQJ7HuFZq69L0ioSaGwaSY0U vMLU5PGqHHyDefkuTB4Zf3k= X-Google-Smtp-Source: AKy350bsm+vn3a5EfZd7qqPwfi4wJipg+CMsIHL2EBdguuECKMWmIqMU5eReJ+valcZl+el/uJP5bA== X-Received: by 2002:a5d:4e47:0:b0:2d5:2c7b:bc5f with SMTP id r7-20020a5d4e47000000b002d52c7bbc5fmr5844752wrt.58.1680728428238; Wed, 05 Apr 2023 14:00:28 -0700 (PDT) Received: from [192.168.0.160] ([170.253.51.134]) by smtp.gmail.com with ESMTPSA id l6-20020a5d5606000000b002c71b4d476asm15774100wrv.106.2023.04.05.14.00.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Apr 2023 14:00:27 -0700 (PDT) Message-ID: Date: Wed, 5 Apr 2023 23:00:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [RFC PATCH] malloc_usable_size.3: Warn about _FORTIFY_SOURCE interaction Content-Language: en-US To: Wilco Dijkstra Cc: 'GNU C Library' , Siddhesh Poyarekar References: From: Alejandro Colomar In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------2QTN9ukBTVe3DtR6QDDRrQQk" X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------2QTN9ukBTVe3DtR6QDDRrQQk Content-Type: multipart/mixed; boundary="------------rf5NN5SBz7vlPgxgua7HXM0p"; protected-headers="v1" From: Alejandro Colomar To: Wilco Dijkstra Cc: 'GNU C Library' , Siddhesh Poyarekar Message-ID: Subject: Re: [RFC PATCH] malloc_usable_size.3: Warn about _FORTIFY_SOURCE interaction References: In-Reply-To: --------------rf5NN5SBz7vlPgxgua7HXM0p Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Wilco, On 4/5/23 15:55, Wilco Dijkstra wrote: > Hi Alejandro, >=20 >> and the header where we define a wrapper macro, which contains several= >> comments about assumptions made about different libc implementations: >> >> >> >> I hope that tells you something. It doesn't tell me anything, but I'm= >> not used to fiddling with allocators. :) >=20 > This looks rather worrying Agree. I've seen all kinds of UB crimes in this codebase. I'm trying to= fix all that, but it's hard to convince maintainers that lived in a cave for = the last few decades and don't know about C99, strict aliasing rules, or over= flow, to change certain code "if it worked so far" for some definition of "work= ed". Of course, it is compiled with -O which is probably what has avoided hell= breaking loose so far (I'm honestly surprised that the performance of ngi= nx is so high compiling with -O, I must admit). > - it seems to deliberately use a malloc size that is too > small in the hope that the particular malloc implementation allocates a= bit more > and then use that extra space. Yes, that's what it looked to me. :/ > So every malloc call now needs extra checks to > adjust the size and another call to malloc_usable_size which then needs= to be > checked to be larger than the original requested size... >=20 > So basically they are trying to save 32 bytes in blocks larger than 128= KB > (a whopping 0.024%!!!) by adding ~64 bytes of extra code per malloc cal= l plus > lots of extra executed instructions... I think it was more like avoiding an entire page just for those 32 bytes = of bookkeeping. So if the bookkeeping would trigger the allocation of a new= page, that is avoided. It seems to be saving (4K - 32) bytes for blocks of >128K, so <3% of the size; still a low number, which I wouldn't trade = for extra code and CPU overhead. Luckily, it seems these macros are not real= ly being called :) >=20 > This kind of stupidity convinces me even more that we need to obsolete > malloc_usable_size - people clearly cannot use it properly or avoid > hardcoding internal implementation details which could change at any ti= me. I would say that not all of us are like that. There's still programmers who respect nasal demons. However, I have never had a reason to call suc= h a function, so I'm not going to be the one that asks you to not remove it= =2E >=20 > Cheers, > Wilco Cheers, Alex --=20 GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 --------------rf5NN5SBz7vlPgxgua7HXM0p-- --------------2QTN9ukBTVe3DtR6QDDRrQQk Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmQt4WMACgkQnowa+77/ 2zIivQ//ddQS/kDck0nurlxiuoxynjdJGd2jlDVYFfZ1ihUMQN/jrwRoEwgTXbdV BQ0SJ08mKQMS+IJUiVaCTyPVhdYB40Zpy8eLrOzij6ZOZ/Ur/vrIwN+XsOmTgKuF uJ74Pb9E1Zb/g77D1+OkSZpIDYFOvo2hafmuAiB1PrGi2tsotoOENeho8n7m20Oz /1Uj2ppXLp3ZAbLkFaGvgyhOxwXzJhrpwX/0BbsiUtkKwGp7rhOQWKutjFK3YpLs 5RMhUQzYIr5NABklUJMNTwxbmarRaULIiEGjVkAiWJwhdvndSi/h6qptwBIw2V3x 4ag5LU9xcONsCQSJ7MHL3OexbLJttD8+vuL2hJIBIaQtG5udXskgbrS9fB1058h/ JhiMZntyjSuXp/MsgrQ3VmYzU3J4S+n3Ed9imzxAlRYnGkiN6xDP1OTW9yBajZic 101h5G7fW2MlbKOorotLu3CIquKR06jAh3KPpbsYTH1zFRIsg/QdpozhdVLtX8Jr ifJWbAMzN2Zk4gMvJ4VL5c8bL3fpUkjXUOj6UNKHc+j0Wfhy54oP0hxjS7NCMHic 1U5IPeN4gifny2pN0HZUGf2RCxyy9/5wf/UWB/WumG4bYaCdJCX5RYeVdR7YPAr0 P6OiZ5JVKVVxmd/kXum9Ii81EO7DouMfYnN7aFPtxNkkQ5d7Jvo= =g1w9 -----END PGP SIGNATURE----- --------------2QTN9ukBTVe3DtR6QDDRrQQk--