From: Peter Xu <peterx@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: farosas@suse.de, eblake@redhat.com, armbru@redhat.com,
pbonzini@redhat.com, qemu-devel@nongnu.org,
yc-core@yandex-team.ru
Subject: Re: [PATCH v5 4/5] migration: process_incoming_migration_co(): rework error reporting
Date: Mon, 29 Apr 2024 15:39:52 -0400 [thread overview]
Message-ID: <Zi_3iEr3imN4C80_@x1n> (raw)
In-Reply-To: <20240429191426.2327225-5-vsementsov@yandex-team.ru>
On Mon, Apr 29, 2024 at 10:14:25PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Unify error reporting in the function. This simplifies the following
> commit, which will not-exit-on-error behavior variant to the function.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> Reviewed-by: Fabiano Rosas <farosas@suse.de>
> ---
> migration/migration.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 58fd5819bc..5489ff96df 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -748,11 +748,12 @@ process_incoming_migration_co(void *opaque)
> MigrationIncomingState *mis = migration_incoming_get_current();
> PostcopyState ps;
> int ret;
> + Error *local_err = NULL;
>
> assert(mis->from_src_file);
>
> if (compress_threads_load_setup(mis->from_src_file)) {
> - error_report("Failed to setup decompress threads");
> + error_setg(&local_err, "Failed to setup decompress threads");
> goto fail;
> }
>
> @@ -789,16 +790,12 @@ process_incoming_migration_co(void *opaque)
> }
>
> if (ret < 0) {
> - if (migrate_has_error(s)) {
> - WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
> - error_report_err(error_copy(s->error));
> - }
> - }
> - error_report("load of migration failed: %s", strerror(-ret));
> + error_setg(&local_err, "load of migration failed: %s", strerror(-ret));
> goto fail;
> }
>
> if (colo_incoming_co() < 0) {
> + error_setg(&local_err, "colo incoming failed");
> goto fail;
> }
>
> @@ -809,6 +806,12 @@ fail:
> MIGRATION_STATUS_FAILED);
> migration_incoming_state_destroy();
>
> + if (migrate_has_error(s)) {
> + WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
> + error_report_err(error_copy(s->error));
> + }
> + }
> + error_report_err(local_err);
Here migrate_has_error() will always return true? If so we can drop it.
Meanwhile, IMHO it's easier we simply always keep the earliest error we see
and report that only, local_err is just one of the errors and whoever
reaches first will be reported. Something like:
migrate_set_error(local_err);
WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
error_report_err(error_copy(s->error));
}
exit(EXIT_FAILURE);
Then when with the exit-on-error thing:
migrate_set_error(local_err);
if (exit_on_error) {
WITH_QEMU_LOCK_GUARD(&s->error_mutex) {
error_report_err(error_copy(s->error));
}
exit(EXIT_FAILURE);
}
Would this looks slightly cleaner?
--
Peter Xu
next prev parent reply other threads:[~2024-04-29 19:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 19:14 [PATCH v5 0/5] migration: do not exit on incoming failure Vladimir Sementsov-Ogievskiy
2024-04-29 19:14 ` [PATCH v5 1/5] migration: move trace-point from migrate_fd_error to migrate_set_error Vladimir Sementsov-Ogievskiy
2024-04-29 19:14 ` [PATCH v5 2/5] migration: process_incoming_migration_co(): complete cleanup on failure Vladimir Sementsov-Ogievskiy
2024-04-29 19:22 ` Peter Xu
2024-04-29 19:14 ` [PATCH v5 3/5] migration: process_incoming_migration_co(): fix reporting s->error Vladimir Sementsov-Ogievskiy
2024-04-29 19:32 ` Peter Xu
2024-04-30 8:06 ` Vladimir Sementsov-Ogievskiy
2024-04-30 8:09 ` Vladimir Sementsov-Ogievskiy
2024-04-30 8:47 ` Vladimir Sementsov-Ogievskiy
2024-04-29 19:14 ` [PATCH v5 4/5] migration: process_incoming_migration_co(): rework error reporting Vladimir Sementsov-Ogievskiy
2024-04-29 19:39 ` Peter Xu [this message]
2024-04-30 7:12 ` Vladimir Sementsov-Ogievskiy
2024-04-29 19:14 ` [PATCH v5 5/5] qapi: introduce exit-on-error parameter for migrate-incoming Vladimir Sementsov-Ogievskiy
2024-04-29 19:41 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zi_3iEr3imN4C80_@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@yandex-team.ru \
--cc=yc-core@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.