[libvirt] [PATCH] qemu: add return value check
Alex Jia
ajia at redhat.com
Tue Sep 27 02:43:46 UTC 2011
On 09/27/2011 06:55 AM, Eric Blake wrote:
> On 09/26/2011 01:52 AM, ajia at redhat.com wrote:
>> From: Alex Jia<ajia at redhat.com>
>>
>> * src/qemu/qemu_migration.c: if 'vmdef' is NULL, the function
>> virDomainSaveConfig still dereferences it, it doesn't make
>> sense, so should add return value check to make sure 'vmdef'
>> is non-NULL before calling virDomainSaveConfig.
>>
>> Signed-off-by: Alex Jia<ajia at redhat.com>
>> ---
>> src/qemu/qemu_migration.c | 8 +++++++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> Good catch, but not quite the right fix.
>
>> +++ b/src/qemu/qemu_migration.c
>> @@ -2580,8 +2580,14 @@ qemuMigrationFinish(struct qemud_driver *driver,
>> vm->persistent = 1;
>> if (mig->persistent)
>> vm->newDef = vmdef = mig->persistent;
>> - else
>> + else {
>
> This violates formatting conventions (if one side of if-else uses {},
> then both must use it).
Because 'if' only includes one statement, I haven't use {} surround with
this statement,
however, the following usage is better:
if {
...
} else {
...
}
>
>> vmdef = virDomainObjGetPersistentDef(driver->caps,
>> vm);
>> + if (!vmdef) {
>> + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s",
>> + _("can't get vmdef"));
>> + goto endjob;
>
> This is wrong for v3proto. A better fix is probably this one,
> although I'd feel more comfortable with Dan reviewing it and/or
> running the TCK migration stress test on it:
>
> diff --git i/src/qemu/qemu_migration.c w/src/qemu/qemu_migration.c
> index 0a5a13d..1bef50a 100644
> --- i/src/qemu/qemu_migration.c
> +++ w/src/qemu/qemu_migration.c
> @@ -2582,7 +2582,8 @@ qemuMigrationFinish(struct qemud_driver *driver,
> vm->newDef = vmdef = mig->persistent;
> else
> vmdef = virDomainObjGetPersistentDef(driver->caps, vm);
> - if (virDomainSaveConfig(driver->configDir, vmdef) < 0) {
> + if (!vmdef ||
> + virDomainSaveConfig(driver->configDir, vmdef) < 0) {
> /* Hmpf. Migration was successful, but making it
> persistent
> * was not. If we report successful, then when this
> domain
> * shuts down, management tools are in for a
> surprise. On the
>
>
Yeah, but in order to debug, whether we still need to write error/debug
log to record
which condition is failed.
Thanks,
Alex
More information about the libvir-list
mailing list