Re: [libvirt] [PATCH 2/4] libxl: MigrateConfirm: Dont unlock virDomainObj in helper function

On 03/13/2018 01:26 PM, Jim Fehlig wrote: > The libxlDomainMigrateConfirm3Params API locks and ref counts the associated > virDomainObj but relies on the helper function libxlDomainMigrationConfirm > to unlock the object. Unref'ing the object is not done in either function. > libxlDomainMigrationConfirm is also used by libxlDomainMigratePerform3Params > for p2p migration, but in that case the lock/ref and unref/unlock are > properly handled in the API entry point. > > Remove the unlock from libxlDomainMigrationConfirm and adjust > libxlDomainMigrateConfirm3Params to properly unref/unlock the virDomainObj > on success and error paths. > > Signed-off-by: Jim Fehlig <jfehlig(a)suse.com&gt; > --- > src/libxl/libxl_driver.c | 13 ++++++++----- > src/libxl/libxl_migration.c | 2 -- > 2 files changed, 8 insertions(+), 7 deletions(-) > > diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c > index eff13e5aa..67a638da0 100644 > --- a/src/libxl/libxl_driver.c > +++ b/src/libxl/libxl_driver.c > @@ -6161,6 +6161,7 @@ libxlDomainMigrateConfirm3Params(virDomainPtr domain, > { > libxlDriverPrivatePtr driver = domain->conn->privateData; > virDomainObjPtr vm = NULL; > + int ret = -1; > > #ifdef LIBXL_HAVE_NO_SUSPEND_RESUME > virReportUnsupportedError(); > @@ -6174,12 +6175,14 @@ libxlDomainMigrateConfirm3Params(virDomainPtr domain, > if (!(vm = libxlDomObjFromDomain(domain))) > return -1; > > - if (virDomainMigrateConfirm3ParamsEnsureACL(domain->conn, vm->def) < 0) { > - virObjectUnlock(vm); > - return -1; > - } > + if (virDomainMigrateConfirm3ParamsEnsureACL(domain->conn, vm->def) < 0) > + goto cleanup; > > - return libxlDomainMigrationConfirm(driver, vm, flags, cancelled); > + ret = libxlDomainMigrationConfirm(driver, vm, flags, cancelled); > + > + cleanup: > + virDomainObjEndAPI(&vm); > + return ret; > } > > static int libxlNodeGetSecurityModel(virConnectPtr conn, > diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c > index 4b848c920..fef1c998b 100644 > --- a/src/libxl/libxl_migration.c > +++ b/src/libxl/libxl_migration.c > @@ -1400,8 +1400,6 @@ libxlDomainMigrationConfirm(libxlDriverPrivatePtr driver, Above here there is a possible call to virDomainObjListRemove which would return @vm w/ at least 1 ref and unlocked. The reason it's "at least 1 ref" is because some call paths in libxl will call virDomainObjListAdd *and* then perform a virObjectRef(vm) while others don't do that ref. Return from ListAdd will have 2 refs and 1 lock on @vm (although it should be 3, hence my other series). It's not necessarily crystal clear which ListAdd was used in this path... In any case, "for now" I think we're mostly OK here because at least @vm was obtained via libxlDomObjFromDomain which will return @vm w/ 1 extra ref and locked (e.g. 3 refs and locked). So calling virDomainObjListRemove will remove 2 refs and the lock. All it means is the EndAPI call done will call Unlock even though it doesn't have the lock. Of course there's no error propagation, so it doesn't hurt. On the upside, the changes will at least allow @vm to be free'd once the EndAPI is called (when @vm refcnt == 0) as opposed to the changes before here where refcnt was never lowered and @vm was probably leaked once/if it was removed from the list. I think what could be done is - after calling ListRemove, you could call virObjectLock(vm) and remove the vm = NULL. That way you know you "leave" this function with at least 1 ref and @vm being locked regardless of what happens. That way the caller using EndAPI will do the right thing too.

Hopefully this makes sense, I have various stages of this ListAdd problem percolating inside my head...