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);
-- 
2.31.0

On Fri, Mar 19, 2021 at 10:42:25PM +0100, 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>
> ---
Reviewed-by: Erik Skultety <eskultet@redhat.com>

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.

Michal

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