[RFC PATCH v3 12/30] migration/multifd: Allow QIOTask error reporting without an object

Fabiano Rosas posted 30 patches 1 year ago
Maintainers: Juan Quintela <quintela@redhat.com>, Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>, Leonardo Bras <leobras@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, David Hildenbrand <david@redhat.com>, "Philippe Mathieu-Daudé" <philmd@linaro.org>, "Daniel P. Berrangé" <berrange@redhat.com>, Eric Blake <eblake@redhat.com>, Markus Armbruster <armbru@redhat.com>, Thomas Huth <thuth@redhat.com>, Laurent Vivier <lvivier@redhat.com>
There is a newer version of this series
[RFC PATCH v3 12/30] migration/multifd: Allow QIOTask error reporting without an object
Posted by Fabiano Rosas 1 year ago
The only way for the channel backend to report an error to the multifd
core during creation is by setting the QIOTask error. We must allow
the channel backend to set the error even if the QIOChannel has failed
to be created, which means the QIOTask source object would be NULL.

At multifd_new_send_channel_async() move the QOM casting of the
channel until after we have checked for the QIOTask error.

Signed-off-by: Fabiano Rosas <farosas@suse.de>
---
context: When doing multifd + file, it's possible that we fail to open
the file. I'll use the empty QIOTask to report the error back to
multifd.
---
 migration/multifd.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/migration/multifd.c b/migration/multifd.c
index 9625640d61..123ff0dec0 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -865,8 +865,7 @@ static bool multifd_channel_connect(MultiFDSendParams *p,
     return true;
 }
 
-static void multifd_new_send_channel_cleanup(MultiFDSendParams *p,
-                                             QIOChannel *ioc, Error *err)
+static void multifd_new_send_channel_cleanup(MultiFDSendParams *p, Error *err)
 {
      migrate_set_error(migrate_get_current(), err);
      /* Error happen, we need to tell who pay attention to me */
@@ -878,20 +877,20 @@ static void multifd_new_send_channel_cleanup(MultiFDSendParams *p,
       * its status.
       */
      p->quit = true;
-     object_unref(OBJECT(ioc));
      error_free(err);
 }
 
 static void multifd_new_send_channel_async(QIOTask *task, gpointer opaque)
 {
     MultiFDSendParams *p = opaque;
-    QIOChannel *ioc = QIO_CHANNEL(qio_task_get_source(task));
+    Object *obj = qio_task_get_source(task);
     Error *local_err = NULL;
 
     trace_multifd_new_send_channel_async(p->id);
     if (!qio_task_propagate_error(task, &local_err)) {
-        p->c = ioc;
-        qio_channel_set_delay(p->c, false);
+        QIOChannel *ioc = QIO_CHANNEL(obj);
+
+        qio_channel_set_delay(ioc, false);
         p->running = true;
         if (multifd_channel_connect(p, ioc, &local_err)) {
             return;
@@ -899,7 +898,8 @@ static void multifd_new_send_channel_async(QIOTask *task, gpointer opaque)
     }
 
     trace_multifd_new_send_channel_async_error(p->id, local_err);
-    multifd_new_send_channel_cleanup(p, ioc, local_err);
+    multifd_new_send_channel_cleanup(p, local_err);
+    object_unref(obj);
 }
 
 static void multifd_new_send_channel_create(gpointer opaque)
-- 
2.35.3
Re: [RFC PATCH v3 12/30] migration/multifd: Allow QIOTask error reporting without an object
Posted by Peter Xu 10 months, 2 weeks ago
On Mon, Nov 27, 2023 at 05:25:54PM -0300, Fabiano Rosas wrote:
> The only way for the channel backend to report an error to the multifd
> core during creation is by setting the QIOTask error. We must allow
> the channel backend to set the error even if the QIOChannel has failed
> to be created, which means the QIOTask source object would be NULL.
> 
> At multifd_new_send_channel_async() move the QOM casting of the
> channel until after we have checked for the QIOTask error.
> 
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> ---
> context: When doing multifd + file, it's possible that we fail to open
> the file. I'll use the empty QIOTask to report the error back to
> multifd.

The "context" can be slightly reworded and put into the commit message too.

Reviewed-by: Peter Xu <peterx@redhat.com>

-- 
Peter Xu