On 03/14/2018 06:43 AM, John Ferlan wrote:
On 03/13/2018 01:26 PM, Jim Fehlig wrote:
The libxlDomainMigrateBegin3Params API locks and ref counts the associated
virDomainObj but relies on the helper function libxlDomainMigrationBegin
to unref/unlock the object. libxlDomainMigrationBegin 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. So
p2p migrations suffer a double unref/unlock in the Perform API.
Remove the unref/unlock (virDomainObjEndAPI) from libxlDomainMigrationBegin
and adjust libxlDomainMigrateBegin3Params to properly unref/unlock
the virDomainObj on success and error paths.
Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>
---
src/libxl/libxl_driver.c | 24 +++++++++++++-----------
src/libxl/libxl_migration.c | 1 -
2 files changed, 13 insertions(+), 12 deletions(-)
Reviewed-by: John Ferlan <jferlan@xxxxxxxxxx>
Thanks for reviewing the series!
BTW: Outside the scope of this series; however, danpb went through the
painstaking task of modifying names of qemu_migration API's such that
it's easier to determine if the API was run on qemuMigrationSrc or
qemuMigrationDst - made it so much easier to remember which was which
w/r/t the various stages - you may want to consider doing that too for
libxl!
Good point. I'm familiar with the code and still find myself thinking about
which phase pertains to the src and which to the dest.
Regards,
Jim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
