From: Avi Kivity <avi@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/6] Terminate emulation on memory allocation failure
Date: Thu, 05 Feb 2009 14:22:39 +0200 [thread overview]
Message-ID: <498ADA0F.80006@redhat.com> (raw)
In-Reply-To: <20090205120115.GJ2759@redhat.com>
Daniel P. Berrange wrote:
> On Thu, Feb 05, 2009 at 01:08:41PM +0200, Avi Kivity wrote:
>
>> Memory allocation failures are a very rare condition on virtual-memory
>> hosts. They are also very difficult to handle correctly (especially in a
>> hardware emulation context). Because of this, it is better to gracefully
>> terminate emulation rather than executing untested or even unwritten recovery
>> code paths.
>>
>> This patch changes the qemu memory allocation routines to terminate emulation
>> if an allocation failure is encountered.
>>
>> Signed-off-by: Avi Kivity <avi@redhat.com>
>> ---
>> qemu-malloc.c | 16 ++++++++++------
>> 1 files changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/qemu-malloc.c b/qemu-malloc.c
>> index dc74efe..1d00f26 100644
>> --- a/qemu-malloc.c
>> +++ b/qemu-malloc.c
>> @@ -22,6 +22,14 @@
>> * THE SOFTWARE.
>> */
>> #include "qemu-common.h"
>> +#include <stdlib.h>
>> +
>> +static void *oom_check(void *ptr)
>> +{
>> + if (ptr == NULL)
>> + exit(13);
>> + return ptr;
>> +}
>>
>
> Will all our atexit handlers cope with OOM too? In particular
> we don't want them calling qemu_malloc again, or this becomes
> re-entrant. If we want to go down this route, then abort() is
> probably safer.
abort() is a little messy in leaving a core file (which would likely
fail anyway if we're out of memory).
Maybe _exit() is better here.
Even exit() will work; if we are unable to allocate in the exit handler,
worst case we overflow the stack and crash.
In any case, I didn't see any calls to qemu_malloc() in existing atexit
handlers.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-02-05 12:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-05 11:08 [Qemu-devel] [PATCH 0/6] Unify memory allocation failure handling Avi Kivity
2009-02-05 11:08 ` [Qemu-devel] [PATCH 1/6] Terminate emulation on memory allocation failure Avi Kivity
2009-02-05 12:01 ` Daniel P. Berrange
2009-02-05 12:22 ` Avi Kivity [this message]
2009-02-05 17:43 ` Ian Jackson
2009-02-05 11:08 ` [Qemu-devel] [PATCH 2/6] block: remove error handling from qemu_malloc() callers Avi Kivity
2009-02-05 11:08 ` [Qemu-devel] [PATCH 3/6] audio: " Avi Kivity
2009-02-05 11:08 ` [Qemu-devel] [PATCH 4/6] hw: " Avi Kivity
2009-02-05 11:08 ` [Qemu-devel] [PATCH 5/6] targets: " Avi Kivity
2009-02-05 11:08 ` [Qemu-devel] [PATCH 6/6] toplevel: " Avi Kivity
2009-02-05 17:43 ` [Qemu-devel] [PATCH 0/6] Unify memory allocation failure handling Ian Jackson
2009-02-05 22:07 ` [Qemu-devel] " Anthony Liguori
2009-02-06 8:47 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=498ADA0F.80006@redhat.com \
--to=avi@redhat.com \
--cc=berrange@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).