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=-8.6 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_FONT_FACE_BAD,HTML_FONT_LOW_CONTRAST, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_KAM_HTML_FONT_INVALID,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8285 invoked from network); 20 Sep 2022 00:14:25 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 00:14:25 -0000 Received: (qmail 1846 invoked by uid 550); 20 Sep 2022 00:14:22 -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 1821 invoked from network); 20 Sep 2022 00:14:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=hFmv3gHzR30RQV6PQM/u2KQ8QoDafBdHzo8LSkAPrvo=; b=efNonOYTadC6scraB05MnXTF4X76hP57bId4JOz/qoQuQ/TrvyLlCpTt7jjaon16JJ xBaB35T2hyJyZgPdadruKsg91WpU1Kqa+VB0hLaNX6v01hiVnM+AuIrp0AgoxAqfHVk7 rEIPXgDqCW5eqxFMksBQ02QnS8pAR11GbPb1wbLFJmmufWwHiMWMhuIWdzzm2YKrKies 4wxR1uTbVV5caPN3SnmUOcMrLreRuS46GcijNfHZ7Z4hNLSRHaLhNhX+VvCok3RJdY9e P+Yc5Ul+/nVuZ1jNakbjGewVuWdSZ6mHm5N90kHa/RFfvK9mwwOS6doOhEO3f2R0IPzG JiSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=hFmv3gHzR30RQV6PQM/u2KQ8QoDafBdHzo8LSkAPrvo=; b=D+qpY3iCLWRL6JqZkYG1dPJ0Hp73Vx0UlMwU+vpBDiJ2zkmW6NyFBGN3Tb/Jy+jube R4ibFtKmsw6dZosyi6mMMjwmre4qBKI0nNDIazjvoJbp+DmmqC8a1tVEv8425HjdX2xJ AAuU+T1Fi9Zx/4yBzKwR1jA3gfABYeyCrmCfz1xq7je6kiVTF5ewYLcO/sx42hynvuYc tLI2FY2riJ6gUt/F/+q2r1tipyOmE7hMCcG7k2HFv6V3ODnXBC2iAnxsXLxq3kb8rSAM O23TF11lEI2RHbrXLyNcvKe00cIS1P3JBFv/mt1hnBpFogkra1wtiGBEBCXArQoqqC4S yAjA== X-Gm-Message-State: ACrzQf3RVVB3GLYpILxXnwAj9J6Qawnt8cXFMXO+G8M4394X4KxkAqY7 VOGHe9ulLVnz4NCmniicoBRcGgO5HtKAC+cCfhKnsA== X-Google-Smtp-Source: AMsMyM4o3cyzYAEpCCv/K+1afhoEYsk/z/IBVY/lY3+Yx8cQE/0fO1Z2lotAa/4G9BdJO7FTjN35/2iet067jH0+nbE= X-Received: by 2002:a0d:f886:0:b0:34d:3ea:1adc with SMTP id i128-20020a0df886000000b0034d03ea1adcmr6693407ywf.130.1663632849204; Mon, 19 Sep 2022 17:14:09 -0700 (PDT) MIME-Version: 1.0 References: <2022091915532777412615@gmail.com> <20220919110829.GA2158779@port70.net> <874jx3h76u.fsf@oldenburg.str.redhat.com> <20220919134659.GO9709@brightrain.aerifal.cx> <2022092001404698842815@gmail.com> In-Reply-To: <2022092001404698842815@gmail.com> From: James Y Knight Date: Mon, 19 Sep 2022 20:13:57 -0400 Message-ID: To: baiyang Cc: musl , Florian Weimer Content-Type: multipart/alternative; boundary="00000000000003e00105e910b5e9" Subject: Re: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) --00000000000003e00105e910b5e9 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 19, 2022 at 1:40 PM baiyang wrote: > Hi James, > > 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. > It returns an accurate value, but it is undefined behavior to actually _use_ that memory. You need to first call realloc -- and when calling realloc, you (probably...) need to access the new memory via the return value of the realloc call, rather than the pointer you passed as input -- even if they happen to have the same integer representation. (Though there's certainly plenty of debate/discussion regarding the exact workings of, and advisability of, such 'pointer provenance" rules...). In any case, calling the function inside the malloc implementation to implement realloc is a different matter entirely from user code calling it. And, note that just because something works for you today doesn't mean it's correct or allowed. It just means that you've been able to get away with it. So far. Until one day it stops working. That's the really fun part of Undefined Behavior... --00000000000003e00105e910b5e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Sep 19, 2022 at= 1:40 PM baiyang <baiyang@gmail.com> wrote:
Hi James,

I look= ed at the code of tcmalloc, but I didn't find any of the problems you m= entioned in the implementation of malloc_usable_size (see: https://github.com/go= ogle/tcmalloc/blob/9179bb884848c30616667ba129bcf9afee114c32/tcmalloc/tcmall= oc.cc#L1099=C2=A0).

On the contr= ary, similar to musl, tcmalloc also directly uses the return value of mallo= c_usable_size in its realloc implementation to determine whether memory nee= ds to be reallocated: https://github.com/google/tcmalloc/blob/9179= bb884848c30616667ba129bcf9afee114c32/tcmalloc/tcmalloc.cc#L1499<= /span>

I think this is enough to show that t= he return value of malloc_usable_size in tcmalloc is accurate and reliable,= otherwise its own realloc will cause a segment fault<= /font>.

It returns an accurate value, but it is undefined behavio= r to actually _use_ that=C2=A0memory. You need to first call realloc -- and= when calling realloc, you (probably...) need to access the new memory via = the return value of the realloc call, rather than the pointer you passed as= input -- even if they happen to have the same integer representation. (Tho= ugh there's certainly plenty of debate/discussion regarding the exact w= orkings of, and advisability of, such 'pointer provenance" rules..= .). In any case, calling the function inside the malloc implementation to i= mplement realloc is a different matter entirely from user code calling it.<= /div>

And, note that just beca= use something works for you today doesn't mean it's correct or allo= wed. It just means that you've been able to get away with it. So far. U= ntil one day it stops working. That's the really fun part of Undefined = Behavior...
--00000000000003e00105e910b5e9--