|
From: | Eric Blake |
Subject: | Re: [PATCH] virtio: vdpa: omit check return of g_malloc |
Date: | Wed, 23 Sep 2020 13:06:15 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
On 9/18/20 8:12 AM, Alex Bennée wrote:
Li Qiang <liq3ea@gmail.com> writes:Philippe Mathieu-Daudé <philmd@redhat.com> 于2020年8月19日周三 下午11:07写道:On 8/19/20 4:43 PM, Li Qiang wrote:If g_malloc fails, the application will be terminated.Which we don't want... better to use g_try_malloc() instead?I don't think so. If g_malloc return NULL it means a critical situation I think terminate the application is OK. Though I don't find any rule/practices the qemu code base uses g_malloc far more than g_try_malloc.g_try_malloc is only for cases you could recover from, by either deferring or doing something else. A straight out of memory failure is fatal. Arguably a bunch of the try_malloc's in the code base should be straight mallocs. The ELF loaders load_symbols does it because I guess having the symbols is a bonus and you could still run the program if a) there was enough memory to run and b) your symbol table was very large.
If the amount of memory being allocated is under user control (such as from an elf header or qcow2 image), you want g_try_malloc() to prevent against malicious users requesting outrageous amounts. But if it is solely under programmer control, where the maximum amount requested is not going to be a problem unless you are already truly out of memory for other reasons, g_malloc() is appropriate. A potential rule of thumb might be that if you know it is less than 1M of memory, it's not worth trying to recover from.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |