From: Peter Xu <peterx@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org, quintela@redhat.com, peter.maydell@linaro.org
Subject: Re: [Qemu-devel] [PATCH] migration/rdma: Fix qemu_rdma_cleanup null check
Date: Fri, 15 Feb 2019 20:01:58 +0800 [thread overview]
Message-ID: <20190215120158.GA3149@xz-x1> (raw)
In-Reply-To: <20190215110056.GB2630@work-vm>
On Fri, Feb 15, 2019 at 11:00:56AM +0000, Dr. David Alan Gilbert wrote:
> * Peter Xu (peterx@redhat.com) wrote:
> > On Thu, Feb 14, 2019 at 06:53:51PM +0000, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > >
> > > If the migration fails before the channel is open (e.g. a bad
> > > address) we end up in the cleanup with rdma->channel==NULL.
> > >
> > > Spotted by Coverity: CID 1398634
> > > Fixes: fbbaacab2758cb3f32a0
> > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > ---
> > > migration/rdma.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/migration/rdma.c b/migration/rdma.c
> > > index 54a3c11540..9fa3b176eb 100644
> > > --- a/migration/rdma.c
> > > +++ b/migration/rdma.c
> > > @@ -2321,7 +2321,9 @@ static void qemu_rdma_cleanup(RDMAContext *rdma)
> > > rdma->connected = false;
> > > }
> > >
> > > - qemu_set_fd_handler(rdma->channel->fd, NULL, NULL, NULL);
> > > + if (rdma->channel) {
> > > + qemu_set_fd_handler(rdma->channel->fd, NULL, NULL, NULL);
> > > + }
> >
> > IIUC there's no strict ordering constraint on resetting the fd
> > handler, then how about simply moving this line into the below "if
> > (rdma->channel)" altogether?
>
> The logic around the closing of the return path makes that check later a
> bit messy; rdma->channel can get set to Null before the other check.
Ah I see, it's the mess by sharing listen_id and channel on
destination side... Maybe we can clean them up along the way? I gave
it a shot:
if (rdma->listen_id && rdma->is_return_path) {
/*
* The return path on the destination side, both listen_id and
* channel are shared with the other context so we skip
* freeing those but simply clear the pointers no matter what.
* The main context will help us to clean these.
*/
rdma->listen_id = NULL;
rdma->channel = NULL;
} else {
/*
* Either the source side, or the main context of the
* destination side: we are responsible for listen_id/channel
*/
if (rdma->listen_id) {
rdma_destroy_id(rdma->listen_id);
rdma->listen_id = NULL;
}
if (rdma->channel) {
qemu_set_fd_handler(rdma->channel->fd, NULL, NULL, NULL);
rdma_destroy_event_channel(rdma->channel);
rdma->channel = NULL;
}
}
I slightly prefer to clean it up (if someone is still going to
maintain the RDMA code... :), but either way is fine to me.
No matter what you prefer:
Reviewed-by: Peter Xu <peterx@redhat.com>
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2019-02-15 12:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 18:53 [Qemu-devel] [PATCH] migration/rdma: Fix qemu_rdma_cleanup null check Dr. David Alan Gilbert (git)
2019-02-15 1:55 ` Peter Xu
2019-02-15 11:00 ` Dr. David Alan Gilbert
2019-02-15 12:01 ` Peter Xu [this message]
2019-02-15 11:30 ` Philippe Mathieu-Daudé
2019-03-05 13:23 ` Dr. David Alan Gilbert
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=20190215120158.GA3149@xz-x1 \
--to=peterx@redhat.com \
--cc=dgilbert@redhat.com \
--cc=peter.maydell@linaro.org \
--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).