All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@suse.de>
To: Het Gala <het.gala@nutanix.com>, qemu-devel@nongnu.org
Cc: prerna.saxena@nutanix.com, quintela@redhat.com,
	dgilbert@redhat.com, pbonzini@redhat.com, berrange@redhat.com,
	armbru@redhat.com, eblake@redhat.com, manish.mishra@nutanix.com,
	aravind.retnakaran@nutanix.com
Subject: Re: [PATCH v11 09/10] migration: Implement MigrateChannelList to hmp migration flow.
Date: Mon, 09 Oct 2023 11:35:40 -0300	[thread overview]
Message-ID: <874jizg8xv.fsf@suse.de> (raw)
In-Reply-To: <f41198b2-bf86-4ef4-9bab-6c834b011ae7@nutanix.com>

Het Gala <het.gala@nutanix.com> writes:

> On 10/4/2023 8:55 PM, Fabiano Rosas wrote:
>> Het Gala<het.gala@nutanix.com>  writes:
>>
>>> Integrate MigrateChannelList with all transport backends
>>> (socket, exec and rdma) for both src and dest migration
>>> endpoints for hmp migration.
>>>
>>> Suggested-by: Aravind Retnakaran<aravind.retnakaran@nutanix.com>
>>> Signed-off-by: Het Gala<het.gala@nutanix.com>
>>> Reviewed-by: Daniel P. Berrangé<berrange@redhat.com>
>>> ---
>>>   migration/migration-hmp-cmds.c | 15 +++++++++++++--
>>>   migration/migration.c          |  5 ++---
>>>   migration/migration.h          |  3 ++-
>>>   3 files changed, 17 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
>>> index a2e6a5c51e..a1657f3d37 100644
>>> --- a/migration/migration-hmp-cmds.c
>>> +++ b/migration/migration-hmp-cmds.c
>>> @@ -441,9 +441,14 @@ void hmp_migrate_incoming(Monitor *mon, const QDict *qdict)
>>>   {
>>>       Error *err = NULL;
>>>       const char *uri = qdict_get_str(qdict, "uri");
>>> +    MigrationChannelList *caps = NULL;
>>> +    g_autoptr(MigrationChannel) channel = g_new0(MigrationChannel, 1);
>> Just the pointer here. If I remember correctly the g_autoptr here would
>> cause a double free when freeing the caps.
>
> Yes, we'll just have 'g_autoptr(MigrationChannel) channel = NULL'.
>
> Is it because inside QAPI_LIST_PREPEND, caps will be refrencing to the 
> same memory as 'channel', we don't need to free channel ?

Slightly different scenario here. Here the issue is that we will free
the caps with qapi_free_MigrationChannel() before returning. Then, at
function exit the g_autoptr will try to free 'channel', which has
already been freed along with 'caps'. That's a double free, I think it
hits an assert inside glib, if I remember correctly.

> I am still not 
> sure what is the right place to use g_steal_pointer(), is this a right 
> place to use (non-error paths) ?

It doesn't look like we need it here. As long as the qapi list has a
reference and we're freeing the caps, then channel should be freed by
that function already.

>>>   
>>> -    qmp_migrate_incoming(uri, false, NULL, &err);
>>> +    migrate_uri_parse(uri, &channel, &err);
>>> +    QAPI_LIST_PREPEND(caps, channel);
>>>   
>>> +    qmp_migrate_incoming(NULL, true, caps, &err);
>>> +    qapi_free_MigrationChannelList(caps);
>>>       hmp_handle_error(mon, err);
>>>   }
>>>   
>>> @@ -730,9 +735,15 @@ void hmp_migrate(Monitor *mon, const QDict *qdict)
>>>       bool resume = qdict_get_try_bool(qdict, "resume", false);
>>>       const char *uri = qdict_get_str(qdict, "uri");
>>>       Error *err = NULL;
>>> +    MigrationChannelList *caps = NULL;
>>> +    g_autoptr(MigrationChannel) channel = g_new0(MigrationChannel, 1);
>> Same here. We free the channel via caps and we attribute it below, no
>> need to allocate.
> Ack.
>>>   
>>> -    qmp_migrate(uri, false, NULL, !!blk, blk, !!inc, inc,
>>> +    migrate_uri_parse(uri, &channel, &err);
>>> +    QAPI_LIST_PREPEND(caps, channel);
>>> +
>>> +    qmp_migrate(NULL, true, caps, !!blk, blk, !!inc, inc,
>>>                    false, false, true, resume, &err);
>>> +    qapi_free_MigrationChannelList(caps);
>>>       if (hmp_handle_error(mon, err)) {
> Regards,
> Het Gala


  reply	other threads:[~2023-10-09 14:37 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-04  7:58 [PATCH v11 00/10] migration: Modify 'migrate' and 'migrate-incoming' QAPI commands for migration Het Gala
2023-10-04  7:58 ` [PATCH v11 01/10] migration: New QAPI type 'MigrateAddress' Het Gala
2023-10-04  7:58 ` [PATCH v11 02/10] migration: convert migration 'uri' into 'MigrateAddress' Het Gala
2023-10-04 11:48   ` Juan Quintela
2023-10-04 11:52   ` Juan Quintela
2023-10-04 14:43   ` Fabiano Rosas
2023-10-04 17:58     ` Daniel P. Berrangé
2023-10-04 18:12       ` Fabiano Rosas
2023-10-07 11:35         ` Het Gala
2023-10-09 14:13           ` Fabiano Rosas
2023-10-09 15:06             ` Het Gala
2023-10-07  9:01     ` Het Gala
2023-10-04  7:58 ` [PATCH v11 03/10] migration: convert socket backend to accept MigrateAddress Het Gala
2023-10-04  7:58 ` [PATCH v11 04/10] migration: convert rdma " Het Gala
2023-10-04  7:58 ` [PATCH v11 05/10] migration: convert exec " Het Gala
2023-10-04 14:55   ` Fabiano Rosas
2023-10-07 12:36     ` Het Gala
2023-10-04  7:58 ` [PATCH v11 06/10] migration: New migrate and migrate-incoming argument 'channels' Het Gala
2023-10-04  7:58 ` [PATCH v11 07/10] migration: modify migration_channels_and_uri_compatible() for new QAPI syntax Het Gala
2023-10-04  7:58 ` [PATCH v11 08/10] migration: Implement MigrateChannelList to qmp migration flow Het Gala
2023-10-04 15:21   ` Fabiano Rosas
2023-10-07 16:25     ` Het Gala
2023-10-09 14:29       ` Fabiano Rosas
2023-10-10  5:17         ` Het Gala
2023-10-04  7:58 ` [PATCH v11 09/10] migration: Implement MigrateChannelList to hmp " Het Gala
2023-10-04 15:25   ` Fabiano Rosas
2023-10-07 16:56     ` Het Gala
2023-10-09 14:35       ` Fabiano Rosas [this message]
2023-10-10  5:20         ` Het Gala
2023-10-04  7:58 ` [PATCH v11 10/10] migration: modify test_multifd_tcp_none() to use new QAPI syntax Het Gala
2023-10-04 15:25   ` Fabiano Rosas
2023-10-09 13:17     ` Het Gala
2023-10-04 13:33 ` [PATCH v11 00/10] migration: Modify 'migrate' and 'migrate-incoming' QAPI commands for migration Fabiano Rosas
2023-10-04 13:45   ` Het Gala
2023-10-04 14:03     ` Fabiano Rosas
2023-10-04 15:32       ` Fabiano Rosas
2023-10-09 13:25         ` Het Gala
2023-10-06 16:17       ` Het Gala

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=874jizg8xv.fsf@suse.de \
    --to=farosas@suse.de \
    --cc=aravind.retnakaran@nutanix.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=het.gala@nutanix.com \
    --cc=manish.mishra@nutanix.com \
    --cc=pbonzini@redhat.com \
    --cc=prerna.saxena@nutanix.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.