This bug was fixed in the package zlib - 1:1.2.11.dfsg-2ubuntu1.2
---------------
zlib (1:1.2.11.dfsg-2ubuntu1.2) focal; urgency=medium
* Cherrypick update of s390x hw acceleration #410 pull request patch,
which corrects inflateSyncPoint() return value to always gracefully
fail when hw acceleration is in use. This fixes rsync failure with
zlib compression on hw accelerated s390x. LP: #1899621
-- Dimitri John Ledkov <x...@ubuntu.com> Thu, 15 Oct 2020 11:10:29
+0100
** Changed in: zlib (Ubuntu Focal)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1899621
Title:
[Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on
z15
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in zlib package in Ubuntu:
Fix Released
Status in zlib source package in Focal:
Fix Released
Status in zlib source package in Groovy:
Fix Released
Bug description:
Description: zlib: inflateSyncPoint() returns an incorrect result on z15
Symptom: Certain rsync builds fail with "error in rsync protocol data
stream" on z15.
Problem: inflateSyncPoint() does not take into account the hardware
compression state and returns an incorrect result.
Solution: Make inflateSyncPoint() fail if the hardware compression is on.
The hardware does not provide enough information in order to
implement this function.
[Impact]
* Certain rsync builds fail with "error in rsync protocol data
stream" on z15.
* On ubuntu, rsync normally uses zstd or lz4. But when rsync is
forced to use non-default zlib compression (-z flag) it uses
inflateSyncPoint() API. This can also happen when rsync on the the
other end doesn't support zstd & lz4.
* inflateSyncPoint() does not take into account the hardware
compression state and returns an incorrect result.
* Make inflateSyncPoint() fail if the hardware compression is on. The
hardware does not provide enough information in order to implement
this function.
* Above makes rsync to succeed, when zlib uses hardware compression.
[Test Case]
Reproduction: z15 only: printf 1 >1 && rsync -z 1 2
[Regression Potential]
* inflateSyncPoint API is rarely used. Scanning codesearch, there is
a lot of false positives due to embedded copies of zlib in all the
things. I do see that both rsync and backuppc-rsync use it. It used
during a safety check to ensure that algorithm is not at a sync point
(or that cannot be determined). Nonetheless, returning error is a
safer implementation for this API call.
[Other Info]
* This is a regression introduced by adding & enabling zlib hw
acceleration by default on z15; and discovering using rsync that one
API is implemented incorrectly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1899621/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
