All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: peterx@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com,
	eric.auger.pro@gmail.com
Subject: Re: [PATCH v4] migration: Support gtree migration
Date: Fri, 11 Oct 2019 12:18:13 +0200	[thread overview]
Message-ID: <87k19bwpp6.fsf@trasno.org> (raw)
In-Reply-To: <20191010205242.711-1-eric.auger@redhat.com> (Eric Auger's message of "Thu, 10 Oct 2019 22:52:42 +0200")

Eric Auger <eric.auger@redhat.com> wrote:
> Introduce support for GTree migration. A custom save/restore
> is implemented. Each item is made of a key and a data.
>
> If the key is a pointer to an object, 2 VMSDs are passed into
> the GTree VMStateField.
>
> When putting the items, the tree is traversed in sorted order by
> g_tree_foreach.
>
> On the get() path, gtrees must be allocated using the proper
> key compare, key destroy and value destroy. This must be handled
> beforehand, for example in a pre_load method.
>
> Tests are added to test save/dump of structs containing gtrees
> including the virtio-iommu domain/mappings scenario.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>

I found a bug, you have to respin, go to BUG
(here was a reviewed-by)

But, ....

I didn't noticed on the 1st look

> +    const VMStateDescription *key_vmsd = direct_key ? NULL : &field->vmsd[0];
> +    const VMStateDescription *val_vmsd = direct_key ? &field->vmsd[0] :
> +                                                      &field->vmsd[1];
> +    const char *key_vmsd_name = direct_key ? "direct" : key_vmsd->name;

This is ugly as hell.
We are using a pointer to pass to mean an array, and abuse it.

But once told that, it is not trivial to do this in a proper way.

On the other hand, if you have to respin for any other reason, please
consider changing the meaning of vmsd[0] and [1].

vmsd[0] -> val_t
vmsd[1] -> key_t

if (vmsd[1] == NULL)
   direct_key = true;

    const VMStateDescription *val_vmsd = &field->vmsd[0];
    const VMStateDescription *key_vmsd = &field->vmsd[1]
    const char *key_vmsd_name = key_vmsd ? "direct" : key_vmsd->name;

Same for get_gtree().


> +        if (direct_key) {
> +            key = (void *)(uintptr_t)qemu_get_be64(f);

no g_malloc().

> +        } else {
> +            key = g_malloc0(key_size);
> +            ret = vmstate_load_state(f, key_vmsd, key, version_id);
> +            if (ret) {
> +                error_report("%s : failed to load %s (%d)",
> +                             field->name, key_vmsd->name, ret);
> +                g_free(key);
> +                return ret;
> +            }
> +        }
> +        val = g_malloc0(val_size);
> +        ret = vmstate_load_state(f, val_vmsd, val, version_id);
> +        if (ret) {
> +            error_report("%s : failed to load %s (%d)",
> +                         field->name, val_vmsd->name, ret);
> +            g_free(key);

BUG: Allways free.  This need to be protected by a direct_key(), no?

> +            g_free(val);
> +            return ret;
> +        }
> +        g_tree_insert(tree, key, val);
> +    }
> +    if (count != nnodes) {
> +        error_report("%s inconsistent stream when loading the gtree",
> +                     field->name);

BUG2:  we need to return an error here, right?

> +    }
> +    trace_get_gtree_end(field->name, key_vmsd_name, val_vmsd->name, ret);
> +    return ret;
> +}
> +

Later, Juan.


  parent reply	other threads:[~2019-10-11 10:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 20:52 [PATCH v4] migration: Support gtree migration Eric Auger
2019-10-10 23:51 ` no-reply
2019-10-11  5:19   ` Auger Eric
     [not found]     ` <4ae9a7e2-6446-29cc-a1b6-2d614cf3fa05@redhat.com>
2019-10-11  9:44       ` Sphinx UnpicklingError (was Re: [Patchew-devel] Fwd: Re: [PATCH v4] migration: Support gtree migration) Paolo Bonzini
2019-10-11  5:31 ` [PATCH v4] migration: Support gtree migration Peter Xu
2019-10-11 10:18 ` Juan Quintela [this message]
2019-10-11 11:44   ` Auger Eric

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=87k19bwpp6.fsf@trasno.org \
    --to=quintela@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.