qemu-devel
[Top][All Lists]
Advanced

[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 13:14:58 +0200
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

malc schrieb:
> On Fri, 29 May 2009, Kevin Wolf wrote:
> 
>> malc schrieb:
>>> On Fri, 29 May 2009, Kevin Wolf wrote:
>>>
>>>> malc schrieb:
>>>>> On Fri, 29 May 2009, Kevin Wolf wrote:
>>>>>
> 
> [..snip..]
> 
>>> 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.
> 
> I'll rehash it one last time:
> 
> a. Original code in qcow2 did:
>    p = qemu_malloc(nb_snapshots*sizeof_snapshot);
>    if (!p) return_failure;
> 
> I.e. incorrect, when stuff==0 and platform==SYSV_derivative that picked
> return NULL on size 0 among the IDB choices that standard provides.
> 
> b. Code after oom_check went in
>    p = qemu_malloc(nb_snapshots*sizeof_snapshot);
>    /* check gone */
>    for (i = 0; i < nb_snapshots; i++)
> 
> I.e. incorrect, when stuff==0 and platform ... since oom_check would
> kill it.
> 
> So the code in qcow2 was _never_ correct, not a single time. The fact
> that it wouldn't crash since it doesn't dereference returned pointer
> was/is irrelevant.

In b, it was. It was just qemu_malloc that wasn't correct. Which is why
Eduardo sent a patch to fix it (without aborting innocent code). It
doesn't make sense to adjust all callers to work around a qemu_malloc bug.

Kevin




reply via email to

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