** 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 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 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 -- 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
