Eric Blake <ebl...@redhat.com> writes: > On 12/18/2015 09:48 AM, Daniel P. Berrange wrote: >> On Fri, Dec 18, 2015 at 04:30:47PM +0100, Igor Mammedov wrote: >>> qdev_device_add() currently uses object_new() which >>> will abort if there memory allocation for device instance >>> fails. While it's fine it startup, it is not desirable >>> diring hotplug. >>> >>> Try to allocate memory for object first and fail safely >>> if allocation fails. >>> > >> This just avoids one small malloc failure. >> >>> + object_initialize(dev, obj_size, driver); >> >> This is going to call g_new many more times, so you'll >> still hit OOM almost immediately. eg the call to >> g_hash_table_new_full() in object_initialize_with_type >> will abort on OOM, not to mention anything run in a >> instance constructor function registered against the >> class. There's no way to avoid this given that we have >> chosen to use GLib in QEMU, so I don't really see any >> point in replacing the 'object_new' call with g_try_malloc
Seconded. > We just had a recent thread on it, and I tend to agree that this series > isn't helpful. > > https://lists.gnu.org/archive/html/qemu-devel/2015-12/threads.html#01238 Plenty of arguments there why recovering from scattered random allocation failures isn't useful, and recovering from all of them isn't practical. Limit recovery attempts to big allocations, and spend (some of) the saved cycles on actually testing the recovery code. [...]
