From: Fabiano Rosas <farosas@suse.de>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>,
Leonardo Bras <leobras@redhat.com>
Subject: Re: [PATCH 1/3] migration: Stop marking RP bad after shutdown
Date: Mon, 31 Jul 2023 18:02:56 -0300 [thread overview]
Message-ID: <87cz07yetb.fsf@suse.de> (raw)
In-Reply-To: <ZMQ1LbTl5kGmAG21@x1n>
Peter Xu <peterx@redhat.com> writes:
> On Fri, Jul 28, 2023 at 09:15:14AM -0300, Fabiano Rosas wrote:
>> When waiting for the return path (RP) thread to finish, there is
>> really nothing wrong in the RP if the destination end of the migration
>> stops responding, leaving it stuck.
>>
>> Stop returning an error at that point and leave it to other parts of
>> the code to catch. One such part is the very next routine run by
>> migration_completion() which checks 'to_dst_file' for an error and fails
>> the migration. Another is the RP thread itself when the recvmsg()
>> returns an error.
>>
>> With this we stop marking RP bad from outside of the thread and can
>> reuse await_return_path_close_on_source() in the next patches to wait
>> on the thread during a paused migration.
>>
>> Signed-off-by: Fabiano Rosas <farosas@suse.de>
>> ---
>> migration/migration.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/migration/migration.c b/migration/migration.c
>> index 91bba630a8..051067f8c5 100644
>> --- a/migration/migration.c
>> +++ b/migration/migration.c
>> @@ -2049,7 +2049,6 @@ static int await_return_path_close_on_source(MigrationState *ms)
>> * waiting for the destination.
>> */
>> qemu_file_shutdown(ms->rp_state.from_dst_file);
>> - mark_source_rp_bad(ms);
>> }
>> trace_await_return_path_close_on_source_joining();
>> qemu_thread_join(&ms->rp_state.rp_thread);
>
> The retval of await_return_path_close_on_source() relies on
> ms->rp_state.error. If mark_source_rp_bad() is dropped, is it possible
> that it'll start to return succeed where it used to return failure?
Yep, as described in the commit message, I think it's ok to do that. The
critical part is doing the shutdown. Other instances of
mark_source_rp_bad() continue existing and we continue returning
rp_state.error.
>
> Maybe not a big deal: I see migration_completion() also has another
> qemu_file_get_error() later to catch errors, but I don't know how solid
> that is.
That is the instance I refer to in the commit message. At
await_return_path_close_on_source() we only call mark_source_rp_bad() if
to_dst_file has an error. That will be caught by this
qemu_file_get_error() anyway.
next prev parent reply other threads:[~2023-07-31 21:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 12:15 [PATCH 0/3] Fix segfault on migration return path Fabiano Rosas
2023-07-28 12:15 ` [PATCH 1/3] migration: Stop marking RP bad after shutdown Fabiano Rosas
2023-07-28 21:37 ` Peter Xu
2023-07-31 21:02 ` Fabiano Rosas [this message]
2023-07-31 21:13 ` Fabiano Rosas
2023-07-28 12:15 ` [PATCH 2/3] migration: Simplify calling of await_return_path_close_on_source Fabiano Rosas
2023-07-28 21:39 ` Peter Xu
2023-07-31 12:42 ` Fabiano Rosas
2023-07-31 17:06 ` Peter Xu
2023-07-28 12:15 ` [PATCH 3/3] migration: Replace the return path retry logic Fabiano Rosas
2023-07-28 21:45 ` Peter Xu
2023-07-31 13:04 ` Fabiano Rosas
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=87cz07yetb.fsf@suse.de \
--to=farosas@suse.de \
--cc=leobras@redhat.com \
--cc=peterx@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 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.