On 3/19/21 10:42 PM, Jiri Denemark wrote:
In case an async job spans multiple APIs (e.g., incoming migration) the API that started the job is recorded as the asyncOwnerAPI even though it is no longer running and the owner thread is updated properly to the one currently handling the job. Let's also update asyncOwnerAPI to make it more obvious which is the current (or the most recent) API involved in the job. Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx> --- src/qemu/qemu_domainjob.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_domainjob.c b/src/qemu/qemu_domainjob.c index b58d6837ad..50cfc45f5b 100644 --- a/src/qemu/qemu_domainjob.c +++ b/src/qemu/qemu_domainjob.c @@ -711,7 +711,9 @@ qemuDomainObjSetJobPhase(virQEMUDriverPtr driver, qemuDomainAsyncJobTypeToString(priv->job.asyncJob), qemuDomainAsyncJobPhaseToString(priv->job.asyncJob, phase));- if (priv->job.asyncOwner && me != priv->job.asyncOwner) {+ if (priv->job.asyncOwner == 0) { + priv->job.asyncOwnerAPI = g_strdup(virThreadJobGet()); + } else if (me != priv->job.asyncOwner) { VIR_WARN("'%s' async job is owned by thread %llu", qemuDomainAsyncJobTypeToString(priv->job.asyncJob), priv->job.asyncOwner);
Could this be related to a problem I've reviewed earlier? https://listman.redhat.com/archives/libvir-list/2021-March/msg00933.html Or maybe not. IDK. Michal
