From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9ynF-0003rw-9b for qemu-devel@nongnu.org; Fri, 18 Dec 2015 12:26:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9ynA-0000bk-Sm for qemu-devel@nongnu.org; Fri, 18 Dec 2015 12:26:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9ynA-0000bY-Kz for qemu-devel@nongnu.org; Fri, 18 Dec 2015 12:26:08 -0500 References: <1450452647-118105-1-git-send-email-imammedo@redhat.com> <1450452647-118105-3-git-send-email-imammedo@redhat.com> <20151218164823.GH7228@redhat.com> From: Eric Blake Message-ID: <567441AA.1010309@redhat.com> Date: Fri, 18 Dec 2015 10:26:02 -0700 MIME-Version: 1.0 In-Reply-To: <20151218164823.GH7228@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="woaJ838oOIv5Uv0lmQN9JELvLBgEB0kbg" Subject: Re: [Qemu-devel] [PATCH 2/2] qdev: safely fail device_add if unable to allocate device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , Igor Mammedov Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, afaerber@suse.de, armbru@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --woaJ838oOIv5Uv0lmQN9JELvLBgEB0kbg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. >=20 >> + object_initialize(dev, obj_size, driver); >=20 > 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 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 If the allocation is BIG (as in one megabyte or more), then doing tentative allocation and reporting failure is useful (we still have enough small memory left to meaningfully report the error). But here, objects are unlikely to require a megabyte each (and if you really do have an obj_size that large, given that it is a sizeof(type), we may have other problems on our hands - what does the .h look like that defines a type that big, and how slow does it compile?). We can assume that small allocations will always succeed, because if they fail, even the mere act of trying to gracefully recover and report that failure is likely to malloc more memory, which will recursively fail and hose us worse than exiting right away. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --woaJ838oOIv5Uv0lmQN9JELvLBgEB0kbg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWdEGqAAoJEKeha0olJ0NqDRsIAIMLktlWJIH4eehiVBdiPkbW RzEjo1qaAtGYc26mmDhEGH4heAwSlXU/mMBWNvgDC5LsD8aWpBc6cdHqANrHVoJ+ AXP04Y8saIpO9AnvjMDVXaqPb5OcjyBMyZT+DH4Elk/fTs1QrSdSvuPgKkKRt3Fm Ke+CEdf7c895pIkwxaLl5IwneJXX2PfwzoKbTd+zLGnid4rLb2Mj5MZDgiq0YSbG rCwfwjC7/ajjn3wl1kBSjv20DvULAFDMzYhxjIvfCAnBBpyxj9BXAf34+d9DFMAD JRTfbB6YNXPbUrJRTdFp30YmfIr5e9266cgj4j67qBH4EIXJ5hIe4YZmWDaT570= =0iDv -----END PGP SIGNATURE----- --woaJ838oOIv5Uv0lmQN9JELvLBgEB0kbg--