Re: [Qemu-devel] [PATCH 3/8] migration: support todetectcompression and decompression errors

[Xiao Guangrong]

On 03/28/2018 12:20 PM, Peter Xu wrote:
> On Wed, Mar 28, 2018 at 12:08:19PM +0800, address@hidden wrote:
> > > On Tue, Mar 27, 2018 at 10:35:29PM +0800, Xiao Guangrong wrote:
> > >
> > > > > > No, we can't make the assumption that "error _must_ be caused by page update".
> > > > > > No document/ABI about compress/decompress promised it. :)
> > >
> > > Indeed, I found no good documents about below errors that jiang.biao
> > > pointed out.
> > Hi, Peter
> > The description about the errors comes from here,
> > http://www.zlib.net/manual.html
> > And about the error codes returned by inflate(), they are described as，
> > ** inflate() returns
> > Z_OK if some progress has been made (more input processed or more output 
> > produced),
> > Z_STREAM_END if the end of the compressed data has been reached and all 
> > uncompressed output has been produced,
> > Z_NEED_DICT if a preset dictionary is needed at this point,
> > Z_DATA_ERROR if the input data was corrupted (input stream not conforming to the 
> > zlib format or incorrect check value, in which case strm->msg points to a 
> > string with a more specific error),
> > Z_STREAM_ERROR if the stream structure was inconsistent (for example next_in or 
> > next_out was Z_NULL, or the state was inadvertently written over by the 
> > application),
> > Z_MEM_ERROR if there was not enough memory,
> > Z_BUF_ERROR if no progress was possible or if there was not enough room in the 
> > output buffer when Z_FINISH is used. ...
> > **
>
> Ah yes.  My bad to be so uncareful. :)
>
> > According to the above description, the error caused by page update looks
> > more like tend to return Z_DATA_ERROR, but I do not have env to verify that. :)

No, still lack info to confirm the case of compressing the data being
updated is the only one to return Z_DATA_ERROR. And nothing provided
that no other error condition causes data corrupted will be squeezed
into this error code.

> > As I understand it, the real compress/decompress error cases other than that
> > caused by page update should be rare, maybe the error code is enough to
> > distinguish those if we can verify the the error codes returned by page update
> > and other silent failures by test. If so, we can cut the cost of memcpy.

Please note, compare with other operations, e.g, compression, detect zero page,
etc., memcpy() is not a hot function at all.

> > If not, I agree with Guangrong's idea too. I never read the zlib code and all my
> > information comes from the manual, so if anything inaccurate, pls ignore my
> > option. :)
>
> So I suppose all of us know that alternative now, we just need a solid
> way to confirm the uncertainty.  I'll leave this to Guangrong.

Yes, i still prefer to memcpy() to make it safe enough to protect our production
unless we get enough certainty to figure out the error conditions.

Thanks!