On Thu, May 6, 2021 at 10:04 AM Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Thu, 6 May 2021 at 16:46, Eric Blake <ebl...@redhat.com> 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". > I'll convert the ones in our fork to use that pattern prior to upstreaming. Warner
