From: Peter Xu <peterx@redhat.com>
To: Lukas Straub <lukasstraub2@web.de>
Cc: qemu-devel@nongnu.org, Leonardo Bras <leobras.c@gmail.com>,
berrange@redhat.com,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Juan Quintela <quintela@redhat.com>
Subject: Re: [PATCH v3 1/1] yank: Unregister function when using TLS migration
Date: Tue, 1 Jun 2021 12:04:57 -0400 [thread overview]
Message-ID: <YLZaqcGG6QcZbbkA@t490s> (raw)
In-Reply-To: <20210601173233.3a742bd8@gecko.fritz.box>
On Tue, Jun 01, 2021 at 05:32:33PM +0200, Lukas Straub wrote:
> > I have one pure question not directly related to Leo's patch (probably for
> > Lukas?): we check OBJECT(ioc)->ref == 1 when unregister each function. In what
> > case will the ref be not one?
> >
>
> If a return path is opened with qemu_file_get_return_path(), it will
> take additional references:
>
> qemu_file_get_return_path() (qemu-file.c)
> f->ops->get_return_path() -> channel_get_input_return_path() (qemu-file-channel.c)
> qemu_fopen_channel_input() (qemu-file-channel.c)
> object_ref(OBJECT(ioc))
Makes sense.
Wondering whether it's better to unregister in migrate_fd_cleanup() rather than
channel_close(), as we used to register in migration code rather than in qemu
file wrapper layer. I feel like we can drop the ref==1 check if we move, as
the return path should have been closed when reaching migrate_fd_cleanup()
(similar doubt to multifd_load_cleanup() calls to yank_unregister_function()).
No strong opinion, though..
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2021-06-01 16:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-01 5:40 [PATCH v3 1/1] yank: Unregister function when using TLS migration Leonardo Bras
2021-06-01 11:00 ` Lukas Straub
2021-06-01 17:48 ` Leonardo Brás
2021-06-01 14:50 ` Peter Xu
2021-06-01 15:32 ` Lukas Straub
2021-06-01 16:04 ` Peter Xu [this message]
2021-06-01 20:49 ` Leonardo Brás
2021-06-08 17:51 ` Dr. David Alan Gilbert
2021-06-14 11:57 ` Dr. David Alan Gilbert
2021-06-27 11:10 ` Alexander Graf
2021-06-28 11:28 ` Dr. David Alan Gilbert
2021-06-28 13:12 ` Alexander Graf
2021-06-28 16:35 ` Daniel P. Berrangé
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=YLZaqcGG6QcZbbkA@t490s \
--to=peterx@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=leobras.c@gmail.com \
--cc=lukasstraub2@web.de \
--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).