From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89EB5C433B4 for ; Thu, 6 May 2021 14:28:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 58C526113E for ; Thu, 6 May 2021 14:28:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234806AbhEFO3z (ORCPT ); Thu, 6 May 2021 10:29:55 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:20106 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234665AbhEFO3z (ORCPT ); Thu, 6 May 2021 10:29:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620311336; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Mdbs+8zL0ZsR6n4jgVA72c4nLXnosqzKKX4khM1dLjo=; b=SVcguRnDSSS8Eyx7CIo9b4hlFvW5MZR7ki0pFMW86+1uSAuXGYhSQqPj40c+K3pr1ymW4e 7pwL2EkUsBB5fPRLj3Q92dzoZAyjip0efyon46GA9A9ZWXxzysOW4aq/w5d3n3JmXyGT+6 gYtAIM4v/0nW50xWgUiXx/P3663FDYc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-91-UrRYZ5BMPNC0cG3q7qBqBg-1; Thu, 06 May 2021 10:28:55 -0400 X-MC-Unique: UrRYZ5BMPNC0cG3q7qBqBg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9BEB2801107; Thu, 6 May 2021 14:28:53 +0000 (UTC) Received: from [10.3.113.56] (ovpn-113-56.phx2.redhat.com [10.3.113.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 724BA19D61; Thu, 6 May 2021 14:28:49 +0000 (UTC) Subject: Re: [PATCH v2 0/9] misc: Replace alloca() by g_malloc() To: Warner Losh , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Cc: kvm@vger.kernel.org, QEMU Developers , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Gerd Hoffmann , Paolo Bonzini , =?UTF-8?Q?Alex_Benn=c3=a9e?= References: <20210506133758.1749233-1-philmd@redhat.com> From: Eric Blake Organization: Red Hat, Inc. Message-ID: <476d8b44-cba3-4bf2-d93c-d35736d316c6@redhat.com> Date: Thu, 6 May 2021 09:28:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 5/6/21 9:22 AM, Warner Losh wrote: > On Thu, May 6, 2021 at 7:39 AM Philippe Mathieu-Daudé > wrote: > >> The ALLOCA(3) man-page mentions its "use is discouraged". >> Replace few calls by equivalent GLib malloc(). >> > > Except g_alloc and g_malloc are not at all the same, and you can't drop in > replace one with the other. > > g_alloc allocates stack space on the calling frame that's automatically > freed when the function returns. > g_malloc allocates space from the heap, and calls to it must be matched > with calls to g_free(). > > These patches don't do the latter, as far as I can tell, and so introduce > memory leaks unless there's something I've missed. You missed the g_autofree, whose job is to call g_free() on all points in the control flow where the malloc()d memory goes out of scope (equivalent in expressive power to alloca()d memory going out of scope). Although the code is arguably a bit slower (as heap manipulations are not as cheap as stack manipulations), in the long run that speed penalty is worth the safety factor (since stack manipulations under user control are inherently unsafe). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org