On Mon, Mar 22, 2021 at 11:17:12 +0100, Michal Privoznik wrote:
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@redhat.com> --- 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.
I don't think so. This just making debug and error messages a bit more logical as asyncOwnerAPI is not really used for anything but showing which thread is "hanging" in a job in case another thread times out waiting for a job. Jirka