Re: [PATCH] virtio: vdpa: omit check return of g_malloc

[Eric Blake <eblake@redhat.com>]

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