On Thu, May 04, 2023 at 01:44:39PM +0200, Juan Quintela wrote:
> Fixes this commit, clearly a bad merge after a rebase or similar, it
> should have been its own case since that point.
>
> commit 5b0e9dd46fbda5152566a4a26fd96bc0d0452bf7
> Author: Peter Lieven <p...@kamp.de>
> Date: Tue Jun 24 11:32:36 2014 +0200
>
> migration: catch unknown flag combinations in ram_load
>
> Signed-off-by: Juan Quintela <quint...@redhat.com>
> ---
> migration/ram.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
>
> diff --git a/migration/ram.c b/migration/ram.c
> index 7d81c4a39e..43338e1f5b 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -4445,14 +4445,12 @@ static int ram_load_precopy(QEMUFile *f)
> multifd_recv_sync_main();
> }
> break;
> + case RAM_SAVE_FLAG_HOOK:
> + ram_control_load_hook(f, RAM_CONTROL_HOOK, NULL);
> + break;
> default:
> - if (flags & RAM_SAVE_FLAG_HOOK) {
> - ram_control_load_hook(f, RAM_CONTROL_HOOK, NULL);
The only use of this flag is
rdma.c: qemu_put_be64(f, RAM_SAVE_FLAG_HOOK);
so its is impossible for 'flags' to have other bits set when
we see RAM_SAVE_FLAG_HOOK, so although this change is not
semantically equivalent in the general case, it is equivalent
given our current usage.
Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
