On Mon, 4 Jul 2022 at 17:43, Ilya Leoshkevich <i...@linux.ibm.com> wrote: > > zlib_send_prepare() compresses pages of a running VM. zlib does not > make any thread-safety guarantees with respect to changing deflate() > input concurrently with deflate() [1]. > > One can observe problems due to this with the IBM zEnterprise Data > Compression accelerator capable zlib [2]. When the hardware > acceleration is enabled, migration/multifd/tcp/plain/zlib test fails > intermittently [3] due to sliding window corruption. The accelerator's > architecture explicitly discourages concurrent accesses [4]: > > Page 26-57, "Other Conditions": > > As observed by this CPU, other CPUs, and channel > programs, references to the parameter block, first, > second, and third operands may be multiple-access > references, accesses to these storage locations are > not necessarily block-concurrent, and the sequence > of these accesses or references is undefined. > > Mark Adler pointed out that vanilla zlib performs double fetches under > certain circumstances as well [5], therefore we need to copy data > before passing it to deflate(). > > [1] https://zlib.net/manual.html > [2] https://github.com/madler/zlib/pull/410 > [3] https://lists.nongnu.org/archive/html/qemu-devel/2022-03/msg03988.html > [4] http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf > [5] https://gitlab.com/qemu-project/qemu/-/issues/1099
Is this [5] the wrong link? It's to our issue tracker, not zlib's or a zlib mailing list thread, and it doesn't contain any messages from Mark Adler. thanks -- PMM
