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(a)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