qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Yury Kotov <yury-kotov@yandex-team.ru>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"yc-core@yandex-team.ru" <yc-core@yandex-team.ru>
Subject: Re: [Qemu-devel] [PATCH] migration: Fix handling fd protocol
Date: Thu, 11 Apr 2019 13:39:11 +0100	[thread overview]
Message-ID: <20190411123911.GR3641@redhat.com> (raw)
In-Reply-To: <219131554985898@iva6-8a76e93b6298.qloud-c.yandex.net>

On Thu, Apr 11, 2019 at 03:31:43PM +0300, Yury Kotov wrote:
> 11.04.2019, 15:04, "Daniel P. Berrangé" <berrange@redhat.com>:
> > On Wed, Apr 10, 2019 at 12:26:52PM +0300, Yury Kotov wrote:
> >>  Currently such case is possible for incoming:
> >>  QMP: add-fd (fdset = 0, fd of some file):
> >>      adds fd to fdset 0 and returns QEMU's fd (e.g. 33)
> >>  QMP: migrate-incoming (uri = "fd:33"): fd is stored in QIOChannel *ioc
> >>  ...
> >>  Incoming migration completes and unrefs ioc -> close(33)
> >>  QMP: remove-fd (fdset = 0, fd = 33):
> >>      removes fd from fdset 0 and qemu_close() -> close(33) => double close
> >
> > IMHO this is user error.
> >
> > You've given the FD to QEMU and told it to use it for migration.
> >
> > Once you've done that you should not be calling remove-fd.
> >
> > remove-fd should only be used in some error code path. ie if you
> > have called add-fd, and then some failure means you've decided you
> > can't invoke 'migrate-incoming'. Now you should call "remove-fd".
> >
> > AFAIK, we have never documented that 'add-fd' must be paired
> > with 'remove-fd'.
> >
> > IOW, I think this "fix" is in fact not a fix - it is instead
> > changing the semantics of when "remove-fd" should be used.
> >
> 
> I think it might be user's error but fd is still in cur_mon->fds (in getfd case)
> or in mon_fdsets (in add-fd case). So if fd is still exists in the lists why
> user can't close/remove it?
> 
> So, there are 2 valid options:
> 1) fd is still valid after migration (dup)

If we do this then existing mgmt apps using QEMU who don't expect to need
to call remove-fd are going to be leaking FDs forever.

> 2) fd is closed but also removed from the appropriate list

monitor_get_fd currently leaves the FD on the list.

if all current users of that API are closing the FD
themselves, then we could change that method to remove
it from the list.

Either way the requirements in this area are pooly documented
both from QEMU's internal POV and from mgmt app public QMP pov.


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

WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Yury Kotov <yury-kotov@yandex-team.ru>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"yc-core@yandex-team.ru" <yc-core@yandex-team.ru>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] migration: Fix handling fd protocol
Date: Thu, 11 Apr 2019 13:39:11 +0100	[thread overview]
Message-ID: <20190411123911.GR3641@redhat.com> (raw)
Message-ID: <20190411123911.llAJQCUBTqKSR1gFmxrKL1nNQtqKpf9M1HcVTao3-kI@z> (raw)
In-Reply-To: <219131554985898@iva6-8a76e93b6298.qloud-c.yandex.net>

On Thu, Apr 11, 2019 at 03:31:43PM +0300, Yury Kotov wrote:
> 11.04.2019, 15:04, "Daniel P. Berrangé" <berrange@redhat.com>:
> > On Wed, Apr 10, 2019 at 12:26:52PM +0300, Yury Kotov wrote:
> >>  Currently such case is possible for incoming:
> >>  QMP: add-fd (fdset = 0, fd of some file):
> >>      adds fd to fdset 0 and returns QEMU's fd (e.g. 33)
> >>  QMP: migrate-incoming (uri = "fd:33"): fd is stored in QIOChannel *ioc
> >>  ...
> >>  Incoming migration completes and unrefs ioc -> close(33)
> >>  QMP: remove-fd (fdset = 0, fd = 33):
> >>      removes fd from fdset 0 and qemu_close() -> close(33) => double close
> >
> > IMHO this is user error.
> >
> > You've given the FD to QEMU and told it to use it for migration.
> >
> > Once you've done that you should not be calling remove-fd.
> >
> > remove-fd should only be used in some error code path. ie if you
> > have called add-fd, and then some failure means you've decided you
> > can't invoke 'migrate-incoming'. Now you should call "remove-fd".
> >
> > AFAIK, we have never documented that 'add-fd' must be paired
> > with 'remove-fd'.
> >
> > IOW, I think this "fix" is in fact not a fix - it is instead
> > changing the semantics of when "remove-fd" should be used.
> >
> 
> I think it might be user's error but fd is still in cur_mon->fds (in getfd case)
> or in mon_fdsets (in add-fd case). So if fd is still exists in the lists why
> user can't close/remove it?
> 
> So, there are 2 valid options:
> 1) fd is still valid after migration (dup)

If we do this then existing mgmt apps using QEMU who don't expect to need
to call remove-fd are going to be leaking FDs forever.

> 2) fd is closed but also removed from the appropriate list

monitor_get_fd currently leaves the FD on the list.

if all current users of that API are closing the FD
themselves, then we could change that method to remove
it from the list.

Either way the requirements in this area are pooly documented
both from QEMU's internal POV and from mgmt app public QMP pov.


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


  parent reply	other threads:[~2019-04-11 12:39 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-10  9:26 [Qemu-devel] [PATCH] migration: Fix handling fd protocol Yury Kotov
2019-04-10  9:26 ` Yury Kotov
2019-04-10 10:13 ` no-reply
2019-04-10 10:13   ` no-reply
2019-04-10 13:57 ` Dr. David Alan Gilbert
2019-04-10 13:57   ` Dr. David Alan Gilbert
2019-04-10 14:16   ` Yury Kotov
2019-04-10 14:16     ` Yury Kotov
2019-04-11 12:04 ` Daniel P. Berrangé
2019-04-11 12:04   ` Daniel P. Berrangé
2019-04-11 12:31   ` Yury Kotov
2019-04-11 12:31     ` Yury Kotov
2019-04-11 12:39     ` Daniel P. Berrangé [this message]
2019-04-11 12:39       ` Daniel P. Berrangé
2019-04-11 12:50       ` Yury Kotov
2019-04-11 12:50         ` Yury Kotov
2019-04-15  9:50         ` Yury Kotov
2019-04-15  9:50           ` Yury Kotov
2019-04-15 10:11           ` Daniel P. Berrangé
2019-04-15 10:11             ` Daniel P. Berrangé
2019-04-15 10:17             ` Yury Kotov
2019-04-15 10:17               ` Yury Kotov
2019-04-15 10:24               ` Yury Kotov
2019-04-15 10:24                 ` Yury Kotov
2019-04-15 10:25               ` Daniel P. Berrangé
2019-04-15 10:25                 ` Daniel P. Berrangé
2019-04-15 10:33                 ` Yury Kotov
2019-04-15 10:33                   ` Yury Kotov
2019-04-15 10:47                   ` Daniel P. Berrangé
2019-04-15 10:47                     ` Daniel P. Berrangé
2019-04-15 11:15                     ` Dr. David Alan Gilbert
2019-04-15 11:15                       ` Dr. David Alan Gilbert
2019-04-15 11:19                       ` Daniel P. Berrangé
2019-04-15 11:19                         ` Daniel P. Berrangé
2019-04-15 11:30                         ` Dr. David Alan Gilbert
2019-04-15 11:30                           ` Dr. David Alan Gilbert
2019-04-15 12:20                           ` Yury Kotov
2019-04-15 12:20                             ` Yury Kotov
2019-04-16  9:27                             ` Yury Kotov
2019-04-16  9:27                               ` Yury Kotov
2019-04-16 11:01                           ` Yury Kotov
2019-04-16 11:01                             ` Yury Kotov
2019-04-18 14:19                             ` Dr. David Alan Gilbert
2019-04-18 14:19                               ` Dr. David Alan Gilbert
2019-04-18 15:36                               ` Yury Kotov
2019-04-18 15:36                                 ` Yury Kotov
2019-04-18 16:03                                 ` Dr. David Alan Gilbert
2019-04-18 16:03                                   ` Dr. David Alan Gilbert
2019-04-18 16:25                                   ` Yury Kotov
2019-04-18 16:25                                     ` Yury Kotov
2019-04-18 17:01                                     ` Dr. David Alan Gilbert
2019-04-18 17:01                                       ` Dr. David Alan Gilbert
2019-04-18 17:46                                       ` Yury Kotov
2019-04-18 17:46                                         ` Yury Kotov
2019-05-14  9:36                                         ` Yury Kotov
2019-05-21 16:09                                           ` Yury Kotov

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=20190411123911.GR3641@redhat.com \
    --to=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=yc-core@yandex-team.ru \
    --cc=yury-kotov@yandex-team.ru \
    /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).