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

Launchpad Bug Tracker 1899621 at bugs.launchpad.net
Mon Oct 19 23:56:54 UTC 2020


This bug was fixed in the package zlib - 1:1.2.11.dfsg-2ubuntu4

---------------
zlib (1:1.2.11.dfsg-2ubuntu4) groovy; 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 <xnox at ubuntu.com>  Thu, 15 Oct 2020 11:01:38
+0100

** Changed in: zlib (Ubuntu Groovy)
       Status: In Progress => Fix Released

-- 
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 Release Notes for Ubuntu:
  New
Status in Ubuntu on IBM z Systems:
  New
Status in zlib package in Ubuntu:
  Fix Released
Status in zlib source package in Focal:
  In Progress
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-release-notes/+bug/1899621/+subscriptions



More information about the foundations-bugs mailing list