From: Peter Xu <peterx@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org, "Daniel P . Berrangé" <berrange@redhat.com>
Subject: Re: [PATCH v2 0/2] migration mapped-ram fixes
Date: Thu, 14 Mar 2024 11:22:44 -0400 [thread overview]
Message-ID: <ZfMWRBDN4wPQsOWI@x1n> (raw)
In-Reply-To: <20240313212824.16974-1-farosas@suse.de>
On Wed, Mar 13, 2024 at 06:28:22PM -0300, Fabiano Rosas wrote:
> Hi,
>
> In this v2:
>
> patch 1 - The fix for the ioc leaks, now including the main channel
>
> patch 2 - A fix for an fd: migration case I thought I had written code
> for, but obviously didn't.
Maybe I found one more issue.. I'm looking at fd_start_outgoing_migration().
ioc = qio_channel_new_fd(fd, errp); <----- here the fd is consumed and
then owned by the IOC
if (!ioc) {
close(fd);
return;
}
outgoing_args.fd = fd; <----- here we use the fd again,
and "owned" by outgoing_args
even if it shouldn't?
The problem is outgoing_args.fd will be cleaned up with a close(). I had a
feeling that it's possible it will close() something else if the fd reused
before that close() but after the IOC's. We may want yet another dup() for
outgoing_args.fd?
If you agree, we may also want to avoid doing:
outgoing_args.fd = -1;
We could assert it instead making sure no fd leak.
>
> Thank you for your patience.
>
> based-on: https://gitlab.com/peterx/qemu/-/commits/migration-stable
> CI run: https://gitlab.com/farosas/qemu/-/pipelines/1212483701
>
> Fabiano Rosas (2):
> migration: Fix iocs leaks during file and fd migration
> migration/multifd: Ensure we're not given a socket for file migration
>
> migration/fd.c | 35 +++++++++++---------------
> migration/file.c | 65 ++++++++++++++++++++++++++++++++----------------
> migration/file.h | 1 +
> 3 files changed, 60 insertions(+), 41 deletions(-)
>
> --
> 2.35.3
>
--
Peter Xu
next prev parent reply other threads:[~2024-03-14 15:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 21:28 [PATCH v2 0/2] migration mapped-ram fixes Fabiano Rosas
2024-03-13 21:28 ` [PATCH v2 1/2] migration: Fix iocs leaks during file and fd migration Fabiano Rosas
2024-03-14 15:10 ` Peter Xu
2024-03-13 21:28 ` [PATCH v2 2/2] migration/multifd: Ensure we're not given a socket for file migration Fabiano Rosas
2024-03-14 15:10 ` Peter Xu
2024-03-14 15:43 ` Peter Xu
2024-03-14 16:50 ` Fabiano Rosas
2024-03-14 17:58 ` Peter Xu
2024-03-14 16:44 ` Fabiano Rosas
2024-03-14 17:53 ` Peter Xu
2024-03-14 15:22 ` Peter Xu [this message]
2024-03-14 16:55 ` [PATCH v2 0/2] migration mapped-ram fixes Fabiano Rosas
2024-03-14 17:35 ` Peter Xu
2024-03-14 18:00 ` Peter Xu
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=ZfMWRBDN4wPQsOWI@x1n \
--to=peterx@redhat.com \
--cc=berrange@redhat.com \
--cc=farosas@suse.de \
--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 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).