From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>
Subject: Re: [PATCH 10/16] migration: Handle migration_incoming_setup() errors consistently
Date: Mon, 2 Aug 2021 18:53:20 +0100 [thread overview]
Message-ID: <YQgxEGzjyc17PPqX@work-vm> (raw)
In-Reply-To: <20210720125408.387910-11-armbru@redhat.com>
* Markus Armbruster (armbru@redhat.com) wrote:
> Commit b673eab4e2 "multifd: Make multifd_load_setup() get an Error
> parameter" changed migration_incoming_setup() to take an Error **
> argument, and adjusted the callers accordingly. It neglected to
> change adjust multifd_load_setup(): it still exit()s on error. Clean
> that up.
>
> The error now gets propagated up two call chains: via
> migration_fd_process_incoming() to rdma_accept_incoming_migration(),
> and via migration_ioc_process_incoming() to
> migration_channel_process_incoming(). Both chain ends report the
> error with error_report_err(), but otherwise ignore it. Behavioral
> change: we no longer exit() on this error.
>
> This is consistent with how we handle other errors here, e.g. from
> multifd_recv_new_channel() via migration_ioc_process_incoming() to
> migration_channel_process_incoming(). Wether it's consistently right
> or consistently wrong I can't tell.
>
> Also clean up the return value from the unusual 0 on success, 1 on
> error to the more common true on success, false on error.
>
> Cc: Juan Quintela <quintela@redhat.com>
> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
> migration/migration.c | 27 +++++++++------------------
> 1 file changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 231dc24414..c1c0a48647 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -609,30 +609,25 @@ fail:
> }
>
> /**
> - * @migration_incoming_setup: Setup incoming migration
> - *
> - * Returns 0 for no error or 1 for error
> - *
> + * migration_incoming_setup: Setup incoming migration
> * @f: file for main migration channel
> * @errp: where to put errors
> + *
> + * Returns: %true on success, %false on error.
> */
> -static int migration_incoming_setup(QEMUFile *f, Error **errp)
> +static bool migration_incoming_setup(QEMUFile *f, Error **errp)
> {
> MigrationIncomingState *mis = migration_incoming_get_current();
> - Error *local_err = NULL;
>
> - if (multifd_load_setup(&local_err) != 0) {
> - /* We haven't been able to create multifd threads
> - nothing better to do */
> - error_report_err(local_err);
> - exit(EXIT_FAILURE);
> + if (multifd_load_setup(errp) != 0) {
> + return false;
> }
What I don't know is how well that will survive; for example in
multifd_load_setup it creates multiple threads and calls the recv_setup
member on each thread; now if one of those fails what happens - if we
don't exit, is it cleaned up enough so you can try another
migrate_incoming or is it just going to fall over?
Dave
>
> if (!mis->from_src_file) {
> mis->from_src_file = f;
> }
> qemu_file_set_blocking(f, false);
> - return 0;
> + return true;
> }
>
> void migration_incoming_process(void)
> @@ -675,14 +670,11 @@ static bool postcopy_try_recover(QEMUFile *f)
>
> void migration_fd_process_incoming(QEMUFile *f, Error **errp)
> {
> - Error *local_err = NULL;
> -
> if (postcopy_try_recover(f)) {
> return;
> }
>
> - if (migration_incoming_setup(f, &local_err)) {
> - error_propagate(errp, local_err);
> + if (!migration_incoming_setup(f, errp)) {
> return;
> }
> migration_incoming_process();
> @@ -703,8 +695,7 @@ void migration_ioc_process_incoming(QIOChannel *ioc, Error **errp)
> return;
> }
>
> - if (migration_incoming_setup(f, &local_err)) {
> - error_propagate(errp, local_err);
> + if (!migration_incoming_setup(f, errp)) {
> return;
> }
>
> --
> 2.31.1
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2021-08-02 17:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-20 12:53 [PATCH 00/16] Various error handling fixes and cleanups Markus Armbruster
2021-07-20 12:53 ` [PATCH 01/16] error: Use error_fatal to simplify obvious fatal errors (again) Markus Armbruster
2021-07-20 13:42 ` Eric Blake
2021-07-20 17:55 ` Peter Xu
2021-08-02 19:02 ` Philippe Mathieu-Daudé
2021-08-03 5:44 ` Markus Armbruster
2021-07-20 12:53 ` [PATCH 02/16] spapr: Plug memory leak when we can't add a migration blocker Markus Armbruster
2021-07-20 13:12 ` David Gibson
2021-08-02 18:54 ` Philippe Mathieu-Daudé
2021-07-20 12:53 ` [PATCH 03/16] spapr: Explain purpose of ->fwnmi_migration_blocker more clearly Markus Armbruster
2021-07-21 6:08 ` David Gibson
2021-07-20 12:53 ` [PATCH 04/16] multi-process: Fix pci_proxy_dev_realize() error handling Markus Armbruster
2021-07-20 18:02 ` Philippe Mathieu-Daudé
2021-07-20 20:02 ` Jag Raman
2021-07-20 12:53 ` [PATCH 05/16] vhost-scsi: Plug memory leak on migrate_add_blocker() failure Markus Armbruster
2021-07-20 12:53 ` [PATCH 06/16] i386: Never free migration blocker objects instead of sometimes Markus Armbruster
2021-07-20 12:53 ` [PATCH 07/16] vfio: Avoid error_propagate() after migrate_add_blocker() Markus Armbruster
2021-07-20 18:03 ` Philippe Mathieu-Daudé
2021-07-21 6:24 ` Kirti Wankhede
2021-07-21 9:26 ` Paolo Bonzini
2021-07-21 14:12 ` Markus Armbruster
2021-07-20 12:54 ` [PATCH 08/16] whpx nvmm: Drop useless migrate_del_blocker() Markus Armbruster
2021-07-22 8:04 ` Reinoud Zandijk
2021-07-20 12:54 ` [PATCH 09/16] migration: Unify failure check for migrate_add_blocker() Markus Armbruster
2021-07-20 18:05 ` Philippe Mathieu-Daudé
2021-07-20 12:54 ` [PATCH 10/16] migration: Handle migration_incoming_setup() errors consistently Markus Armbruster
2021-07-20 18:53 ` Eric Blake
2021-07-21 14:12 ` Markus Armbruster
2021-07-20 21:55 ` Pankaj Gupta
2021-08-02 17:53 ` Dr. David Alan Gilbert [this message]
2021-08-03 5:58 ` Markus Armbruster
2021-08-31 12:47 ` Markus Armbruster
2021-07-20 12:54 ` [PATCH 11/16] microvm: Drop dead error handling in microvm_machine_state_init() Markus Armbruster
2021-07-20 13:36 ` Sergio Lopez
2021-07-20 18:06 ` Philippe Mathieu-Daudé
2021-07-20 21:59 ` Pankaj Gupta
2021-07-20 12:54 ` [PATCH 12/16] vhost: Clean up how VhostOpts method vhost_get_config() fails Markus Armbruster
2021-08-02 18:56 ` Philippe Mathieu-Daudé
2021-08-02 18:58 ` Philippe Mathieu-Daudé
2021-08-03 5:48 ` Markus Armbruster
2021-07-20 12:54 ` [PATCH 13/16] vhost: Clean up how VhostOpts method vhost_backend_init() fails Markus Armbruster
2021-08-02 18:59 ` Philippe Mathieu-Daudé
2021-07-20 12:54 ` [PATCH 14/16] Remove superfluous ERRP_GUARD() Markus Armbruster
2021-08-02 19:00 ` Philippe Mathieu-Daudé
2021-07-20 12:54 ` [PATCH 15/16] vl: Clean up -smp error handling Markus Armbruster
2021-07-20 18:07 ` Philippe Mathieu-Daudé
2021-07-20 12:54 ` [PATCH 16/16] vl: Don't continue after -smp help Markus Armbruster
2021-07-20 18:08 ` [PATCH-for-6.1? " Philippe Mathieu-Daudé
2021-07-20 21:57 ` [PATCH " Pankaj Gupta
2021-07-24 0:30 ` [PATCH 00/16] Various error handling fixes and cleanups Michael S. Tsirkin
2021-07-29 13:23 ` Markus Armbruster
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=YQgxEGzjyc17PPqX@work-vm \
--to=dgilbert@redhat.com \
--cc=armbru@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).