Re: [libvirt] [PATCH 03/20] libxl: Properly cleanup after libxlDomObjFromDomain
On 03/11/2018 10:13 PM, Jim Fehlig wrote:
On 03/09/2018 09:47 AM, John Ferlan wrote:
> Commit id '9ac945078' altered libxlDomObjFromDomain to return
> a locked *and* ref counted object for some specific purposes;
> however, it neglected to alter all the consumers of the helper
> to use virDomainObjEndAPI thus leaving many objects with extra
> ref counts.
>
> The two consumers for libxlDomainMigrationConfirm would also
> originally use the libxlDomObjFromDomain API (either from
> libxlDomainMigrateConfirm3Params or libxlDoMigrateP2P via
> libxlDomainMigrationPerformP2P and libxlDomainMigratePerform3Params.
>
> Signed-off-by: John Ferlan <jferlan(a)redhat.com>
> ---
> src/libxl/libxl_driver.c | 86
> ++++++++++++++++-----------------------------
> src/libxl/libxl_migration.c | 3 +-
> 2 files changed, 31 insertions(+), 58 deletions(-)
>
> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index b5101626e..9aa4a293c 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
[...]
For these changes
Reviewed-by: Jim Fehlig <jfehlig(a)suse.com>
Tks -
However the migration APIs need some work.
> @@ -5897,19 +5872,19 @@ libxlDomainMigrateBegin3Params(virDomainPtr
> domain,
> if (STREQ_NULLABLE(vm->def->name, "Domain-0")) {
> virReportError(VIR_ERR_OPERATION_INVALID, "%s",
> _("Domain-0 cannot be migrated"));
> - virObjectUnlock(vm);
> + virDomainObjEndAPI(&vm);
> return NULL;
> }
> if (virDomainMigrateBegin3ParamsEnsureACL(domain->conn,
> vm->def) < 0) {
> - virObjectUnlock(vm);
> + virDomainObjEndAPI(&vm);
> return NULL;
> }
> if (!virDomainObjIsActive(vm)) {
> virReportError(VIR_ERR_OPERATION_INVALID,
> "%s", _("domain is not running"));
> - virObjectUnlock(vm);
> + virDomainObjEndAPI(&vm);
> return NULL;
> }
Not shown here, but the subsequent code calls libxlDomainMigrationBegin
which unrefs and unlocks on exit. libxlDomainMigrationBegin is also
called via libxlDomainMigratePerform3Params when doing p2p migration, in
which case both functions unref/unlock :-(. IMO
libxlDomainMigrationBegin should leave unref/unlock to its callers,
where the ref/locking is done. The same is true for
libxlDomainMigrationConfirm. I can send a patch to fix these problems,
along with a few others I noticed when reviewing the migration code.
Regards,
Jim
Hmm... right, I noticed that the migration API's were treating @vm a bit
oddly. I looked backwards through the call stack figuring I'd got things
right, but certainly having libxlDomainMigrationBegin do that EndAPI is
not good!
I figure getting all these patches reviewed could take some time, so if
you want to clean up the libxlDomainMigration paths as you note that'd
be fine. If it becomes problematic trying to work thru things without
pushing what's R-B'd so far in libxl, I can do so. I can also merge in
what you can get done into my changes. Whatever works best.
Tks -
John
> @@ -6085,8 +6060,7 @@
libxlDomainMigratePerform3Params(virDomainPtr
> dom,
> ret = 0;
> cleanup:
> - if (vm)
> - virObjectUnlock(vm);
> + virDomainObjEndAPI(&vm);
> return ret;
> }
> @@ -6174,7 +6148,7 @@ libxlDomainMigrateConfirm3Params(virDomainPtr
> domain,
> return -1;
> if (virDomainMigrateConfirm3ParamsEnsureACL(domain->conn,
> vm->def) < 0) {
> - virObjectUnlock(vm);
> + virDomainObjEndAPI(&vm);
> return -1;
> }
> diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
> index ccf2daed1..21476f7ac 100644
> --- a/src/libxl/libxl_migration.c
> +++ b/src/libxl/libxl_migration.c
> @@ -1401,8 +1401,7 @@
> libxlDomainMigrationConfirm(libxlDriverPrivatePtr driver,
> cleanup:
> if (event)
> libxlDomainEventQueue(driver, event);
> - if (vm)
> - virObjectUnlock(vm);
> + virDomainObjEndAPI(&vm);
> virObjectUnref(cfg);
> return ret;
> }
>