[Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15

[Frank Heimes]

If you follow the above link (comment #11):
https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#zlib
and click on the s390x status [here 'not a regression'], you should eventually find it - or just directly look here:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/b/burp/20201020_215047_4c004@/log.gz

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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 Committed
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