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

[Dimitri John Ledkov]

** Description changed:

  Description:   zlib: inflateSyncPoint() returns an incorrect result on z15
  Symptom:       Certain rsync builds fail with "error in rsync protocol data
-                stream" on z15.
+                stream" on z15.
  Problem:       inflateSyncPoint() does not take into account the hardware
-                compression state and returns an incorrect result.
+                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.
+                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.
+ 
+  * rsync with non-default zlib compression (-z flag) uses
+ inflateSyncPoint() API.
+ 
+  * 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.

** Description changed:

  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]
  
- [Impact] 
- 
-  * Certain rsync builds fail with "error in rsync protocol data stream"
+  * Certain rsync builds fail with "error in rsync protocol data stream"
  on z15.
  
-  * rsync with non-default zlib compression (-z flag) uses
- inflateSyncPoint() API.
+  * 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
+  * 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
+  * 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.
+  * 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
+  * 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.
+ 
+  * 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.

-- 
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:
  New
Status in zlib source package in Focal:
  New
Status in zlib source package in Groovy:
  New

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