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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 2B8CAC433ED for ; Thu, 6 May 2021 16:04:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DE72861078 for ; Thu, 6 May 2021 16:04:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235583AbhEFQFm (ORCPT ); Thu, 6 May 2021 12:05:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235156AbhEFQFk (ORCPT ); Thu, 6 May 2021 12:05:40 -0400 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88082C061574 for ; Thu, 6 May 2021 09:04:42 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id m12so9087037eja.2 for ; Thu, 06 May 2021 09:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C736AuqidzDQYfgZUZZB0PARKzaD4iAVzFxsLnZvVFc=; b=n1fAETreJFQdC7wXEx5ii+pfu/gGH9b/X8P5A9SX9BGHF7EutNs8G9WP/6DeQ2UEEz lf3SV4glmo9fE8fMqGf/+JMh4m+fmRshQpmQh79Olzk5LYno3JkeOfytqEKfk/VclzzJ of6IX46ugieYUfWu0eEiMPC/A/nIUtuPLE3+dgdoXM7BCZ5ZEewe7BI/qNpNP4P7/eqh x1uCSUJPNDOvt3uq/6X68SpaE2eiJRn/D2v+9sJrdNQqvEXBFt5cxsJ77XFujzRe9E0u dJSkDbtfDPNtAd+q/qcFmWTw3MJND80Z31hpZSed3D3dtCJNSiU41yxdRE0pLc5YIdKB vSng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C736AuqidzDQYfgZUZZB0PARKzaD4iAVzFxsLnZvVFc=; b=QsThg7pvm5+Iec5VRulg/kpgVTOIKbLCWDzYTAIwIV1edpC4SsF2ps0x1kryTx+fYk D/jKHN6CwSkzmfoWIAVHVR4UXFTRkh+gDiJT7A0zOO0hQwtIjoSDsr3DYbDm3tzm5fAs IdoefsgJgxzW76DgKg7ZlRIpL4m9hvjI3Ye+vrhI/gzPFiBmHWM3jZI9RbWbZ5TU0oqq 5WNVP+1mE9i8ZTmlGRRNHfAJVVnn4aX3WiAO1O4bZDyoW2gNYrF78V+6cCmkMHPNM7AG IDX0uMGj7MmaDFyAmxVxGsVDgroakLIh8NT0B2AyJL/H7iUOnCI4k8twm1u3LOYy0Utl YT8A== X-Gm-Message-State: AOAM530VGGfzwPdCD9Q946yPEn7dhhaStRw7fIjjKSFOEHPnapU4E81q tUeMLg1fc2KJE1V46sHxZiZvMX5hcTUtggD/OVqndg== X-Google-Smtp-Source: ABdhPJxWQt3yjMYSuWKONmSU3rQ4pt6tgqkHulEIhHw9fFhEGRGThw0EfZS8dZ2aVL+Wv3z1hTcsyguw7VV4nt7m6PE= X-Received: by 2002:a17:906:b1cc:: with SMTP id bv12mr5163395ejb.407.1620317081062; Thu, 06 May 2021 09:04:41 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Peter Maydell Date: Thu, 6 May 2021 17:03:33 +0100 Message-ID: Subject: Re: [PATCH v2 4/9] bsd-user/syscall: Replace alloca() by g_new() To: Eric Blake Cc: Warner Losh , kvm-devel , Kyle Evans , QEMU Developers , =?UTF-8?B?QWxleCBCZW5uw6ll?= , qemu-arm , qemu-ppc , Gerd Hoffmann , Paolo Bonzini , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 6 May 2021 at 16:46, Eric Blake wrote: > > 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? In *-user the allocas are generally of the form "guest passed us a random number, allocate that many structs/whatevers". (In this specific bsd-user example it's the writev syscall and it's "however many struct iovecs the guest passed".) So there is no upper limit. The right thing to do here is probably to use g_try_malloc() and return ENOMEM or whatever on failure. The use of alloca, at least in the linux-user code, is purely old lazy coding based on "in practice real world guest binaries don't allocate very many of these so we can get away with shoving them on the stack". thanks -- PMM