From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Xiao Guangrong <guangrong.xiao@gmail.com>
Cc: Peter Xu <peterx@redhat.com>,
pbonzini@redhat.com, mst@redhat.com, mtosatti@redhat.com,
qemu-devel@nongnu.org, kvm@vger.kernel.org, wei.w.wang@intel.com,
jiang.biao2@zte.com.cn, eblake@redhat.com,
Xiao Guangrong <xiaoguangrong@tencent.com>
Subject: Re: [Qemu-devel] [PATCH v3 08/10] migration: handle the error condition properly
Date: Wed, 8 Aug 2018 15:11:13 +0100 [thread overview]
Message-ID: <20180808141112.GK2734@work-vm> (raw)
In-Reply-To: <503d7733-e2e7-09c5-75a3-1e250f549065@gmail.com>
* Xiao Guangrong (guangrong.xiao@gmail.com) wrote:
>
>
> On 08/08/2018 01:08 PM, Peter Xu wrote:
> > On Tue, Aug 07, 2018 at 05:12:07PM +0800, guangrong.xiao@gmail.com wrote:
> > > From: Xiao Guangrong <xiaoguangrong@tencent.com>
> > >
> > > ram_find_and_save_block() can return negative if any error hanppens,
> > > however, it is completely ignored in current code
> >
> > Could you hint me where we'll return an error?
> >
>
> I think control_save_page() may return a error condition but i am not
> good at it ... Other places look safe _currently_. These functions were
> designed to have error returned anyway.
ram_control_save_page's return is checked by control_save_page which
returns true/false but sets *pages to a return value.
What I'd need to follow closely is the case where ram_control_save_page
returns RAM_SAVE_CONTROL_DELAYED, in that case control_save_page I think
returns with *pages=-1 and returns true.
And I think in that case ram_save_target_page can leak that -1 - hmm.
Now, ram_save_host_page already checks for <0 and will return that,
but I think that would potentially loop in ram_find_and_save_block; I'm
not sure we want to change that or not!
Dave
>
> > (Anyway I agree that the error handling is not that good, mostly
> > because the QEMUFile APIs does not provide proper return code, e.g.,
> > qemu_put_be64 returns void)
> >
>
> Yes, it is, the returned error condition is mixed in file's API and
> function's return value... :(
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2018-08-08 14:11 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 9:11 [Qemu-devel] [PATCH v3 00/10] migration: compression optimization guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 01/10] migration: do not wait for free thread guangrong.xiao
2018-08-07 13:29 ` Eric Blake
2018-08-08 3:51 ` Peter Xu
2018-08-08 6:20 ` Xiao Guangrong
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 02/10] migration: fix counting normal page for compression guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 03/10] migration: introduce save_zero_page_to_file guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 04/10] migration: drop the return value of do_compress_ram_page guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 05/10] migration: move handle of zero page to the thread guangrong.xiao
2018-08-08 4:39 ` Peter Xu
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 06/10] migration: hold the lock only if it is really needed guangrong.xiao
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 07/10] migration: do not flush_compressed_data at the end of each iteration guangrong.xiao
2018-08-08 4:52 ` Peter Xu
2018-08-08 6:22 ` Xiao Guangrong
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 08/10] migration: handle the error condition properly guangrong.xiao
2018-08-08 5:08 ` Peter Xu
2018-08-08 6:29 ` Xiao Guangrong
2018-08-08 6:56 ` Peter Xu
2018-08-08 7:23 ` Xiao Guangrong
2018-08-08 8:46 ` Peter Xu
2018-08-08 14:11 ` Dr. David Alan Gilbert [this message]
2018-08-09 3:08 ` Xiao Guangrong
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 09/10] migration: fix calculating xbzrle_counters.cache_miss_rate guangrong.xiao
2018-08-08 6:05 ` Peter Xu
2018-08-08 6:36 ` Xiao Guangrong
2018-08-08 6:59 ` Peter Xu
2018-08-07 9:12 ` [Qemu-devel] [PATCH v3 10/10] migration: show the statistics of compression guangrong.xiao
2018-08-08 6:12 ` Peter Xu
2018-08-09 3:13 ` Xiao Guangrong
2018-08-09 3:34 ` 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=20180808141112.GK2734@work-vm \
--to=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=guangrong.xiao@gmail.com \
--cc=jiang.biao2@zte.com.cn \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wei.w.wang@intel.com \
--cc=xiaoguangrong@tencent.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).