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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 6CF2AC433ED for ; Thu, 6 May 2021 15:45:05 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BF606610A1 for ; Thu, 6 May 2021 15:45:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF606610A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:52084 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1legBT-0001yr-LR for qemu-devel@archiver.kernel.org; Thu, 06 May 2021 11:45:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51588) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leg9W-0000w6-PE for qemu-devel@nongnu.org; Thu, 06 May 2021 11:43:02 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:27550) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leg9T-000282-Tb for qemu-devel@nongnu.org; Thu, 06 May 2021 11:43:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620315778; 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=4KmRXMHEZ+tVNwwgfG0qof+36HnLMbB1FdIrxdalX6M=; b=eAEuhkWrz7fDs3gILn4J8VOfGgNDErIJa4hxu764eiCT3rqQZMKB7zwYVca6vyOo1WqzOm yT2E4iSYUla+LdPMd3NwJ/a9RFLd+RpnUBWhZH5cF9frXpdHQ24sB1/kT5PRt0MYmEz/op 40PdqRZDB+NnjKOHmBE0IaN27Mp/zEM= 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-222-HqYu6-wIOUGL-HnIy_9qew-1; Thu, 06 May 2021 11:42:56 -0400 X-MC-Unique: HqYu6-wIOUGL-HnIy_9qew-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D196D80ED9B; Thu, 6 May 2021 15:42:54 +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 A7CAE60862; Thu, 6 May 2021 15:42:50 +0000 (UTC) Subject: Re: [PATCH v2 4/9] bsd-user/syscall: Replace alloca() by g_new() To: Warner Losh References: <20210506133758.1749233-1-philmd@redhat.com> <20210506133758.1749233-5-philmd@redhat.com> <39f12704-af5c-2e4f-d872-a860d9a870d7@redhat.com> <7a96d45e-2bdc-f699-96f7-3fbf607cb06b@redhat.com> From: Eric Blake Organization: Red Hat, Inc. Message-ID: Date: Thu, 6 May 2021 10:42:50 -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: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Received-SPF: pass client-ip=170.10.133.124; envelope-from=eblake@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.69, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm-devel , Kyle Evans , QEMU Developers , =?UTF-8?Q?Alex_Benn=c3=a9e?= , qemu-arm , qemu-ppc , Gerd Hoffmann , Paolo Bonzini , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 5/6/21 10:30 AM, Warner Losh wrote: > > But for the real answer, I need to contact the original authors of > this part of the code (they are no longer involved day-to-day in > the bsd-user efforts) to see if this scenario is possible or not. If > it's easy to find out that way, we can either know this is safe to > do, or if effort is needed to make it safe. At present, I've seen > enough and chatted enough with others to be concerned that > the change would break proper emulation. Do we have a feel for the maximum amount of memory being used by the various alloca() replaced in this series? If so, can we just stack-allocate an array of bytes of the maximum size needed? Then we avoid alloca() but also avoid the dynamic memory management that malloc() would introduce. Basically, it boils down to auditing why the alloca() is safe, and once we know that, replacing the variable-sized precise alloca() with its counterpart statically-sized array allocation, at the expense of some wasted stack space when the runtime size does not use the full compile-time maximum size. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org