On 09/27/2011 06:55 AM, Eric Blake wrote:
On 09/26/2011 01:52 AM, ajia@xxxxxxxxxx wrote:
From: Alex Jia<ajia@xxxxxxxxxx>
* 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@xxxxxxxxxx>
---
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list