All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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 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.