[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
Date: Fri, 29 May 2009 12:49:01 +0200
User-agent: Thunderbird (X11/20090320)

malc schrieb:
> On Fri, 29 May 2009, Kevin Wolf wrote:
>> malc schrieb:
>>> On Fri, 29 May 2009, Kevin Wolf wrote:
>>>> malc schrieb:
>>>>>> Putting the abort() in there is going to introduce a ton of subtle bugs,
>>>>>> I vote for changing qemu_malloc() to have a sane behavior.
>>>>> And those will be caught, given one a chance to analyze things, unlike
>>>>> head in the sand approach of hoping things would just work.
>>>>> After doing some research, after the aforementioned lengthy discussion,
>>>>> the only free OS that straight-forwardly described what it does was
>>>>> OpenBSD:
>>>>> http://www.openbsd.org/cgi-bin/man.cgi?query=malloc&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
>>>>> P.S. So far the abort that went into qemu_malloc caught one usage of zero
>>>>>      allocation (once again coming from qcow2).
>>>> Zero allocation isn't a bug per se. Checking for NULL or dereferencing
>>>> is. Any value that can be freed, be it NULL or anything else, was
>>>> perfectly fine here without the abort() patch. So it actually was one of
>>>> the subtle bugs Anthony mentioned which are introduced by the abort().
>>> And once again, the code would have aborted on AIX with our without abort
>>> patch. The reason for abort is to identify and reason about all the call
>>> sites that do that.
>> Why would it have aborted? If AIX aborts on malloc(0), its malloc is
>> seriously broken. But as I have understood from previous discussion, AIX
>> just returns NULL. Would have been okay for this code.
> Because of oom_check in qemu_malloc.

Ok, you're right there, of course. This is a bug in qemu_malloc and the
reason why we even discussed changing the check in qemu_malloc.

But this is not qcow2's fault, so the fix should really be local to
qemu_malloc like it already was for qemu_realloc.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]