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 13:35:09 -0400 [thread overview]
Message-ID: <ZfM1TXP87Jw2jZBT@x1n> (raw)
In-Reply-To: <87plvwvjlo.fsf@suse.de>
On Thu, Mar 14, 2024 at 01:55:31PM -0300, Fabiano Rosas wrote:
> Peter Xu <peterx@redhat.com> writes:
>
> > 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?
>
> I think the right fix is to not close() it at
> fd_cleanup_outgoing_migration(). That fd is already owned by the ioc.
But outgoing_args.fd can point to other things if the IOC (along with the
ioc->fd) is released. Keeping outgoing_args.fd pointing to that fd index
should be dangerous because the integer can be reused.
>
> >
> > If you agree, we may also want to avoid doing:
> >
> > outgoing_args.fd = -1;
>
> We will always need this. This is just initialization of the field
> because 0 is a valid fd value. Otherwise the file.c code can't know if
> we're actually using an fd at all.
I meant avoid setting it to -1 only in fd_start_outgoing_migration().
Using -1 to represent "no fd" is fine.
>
> @file_send_channel_create:
>
> int fd = fd_args_get_fd();
>
> if (fd && fd != -1) {
> <new IOC from fd>
> } else {
> <new IOC from file name>
> }
>
> >
> > 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 17:36 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 ` [PATCH v2 0/2] migration mapped-ram fixes Peter Xu
2024-03-14 16:55 ` Fabiano Rosas
2024-03-14 17:35 ` Peter Xu [this message]
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=ZfM1TXP87Jw2jZBT@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).