Re: [PATCH 1/1] lib/zlib: DFLTCC deflate does not write all available bits for Z_NO_FLUSH

[Zaslonko Mikhail <zaslonko@linux.ibm.com>]

Hello Andrew,

On 23.02.2023 21:54, Andrew Morton wrote:
> On Tue, 21 Feb 2023 14:16:17 +0100 Mikhail Zaslonko <zaslonko@linux.ibm.com> wrote:
> 
>> DFLTCC deflate with Z_NO_FLUSH might generate a corrupted stream when
>> the output buffer is not large enough to fit all the deflate output at
>> once. The problem takes place on closing the deflate block since
>> flush_pending() might leave some output bits not written.
>> Similar problem for software deflate with Z_BLOCK flush option (not
>> supported by kernel zlib deflate) has been fixed a while ago in userspace
>> zlib but the fix never got to the kernel.
>> Now flush_pending() flushes the bit buffer before copying out the byte buffer,
>> in order to really flush as much as possible.
>> Currently there are no users of DFLTCC deflate with Z_NO_FLUSH option in the
>> kernel so the problem remained hidden for a while.
>>
>> This commit is based on the old zlib commit:
>> https://github.com/madler/zlib/commit/0b828b4
>>
> 
> Thanks.  Does this fix make sense when your series "lib/zlib: Set of
> s390 DFLTCC related patches for kernel zlib" is not applied?  If so
> then should we backport it in to earlier kernels?

This fix is separate and does not require a previous zlib patch series.
Although there are no users of s390 hardware deflate with Z_NO_FLUSH at the moment, 
we might still backport this fix to avoid potential issues in the future.
For all my zlib patches the following tag can be used:
  Fixes: aa5b395b69b6 ("lib/zlib: add s390 hardware support for kernel zlib_deflate")

> 
> If "no" then are you able to identify a suitable Fixes: tag?  So that
> anyone who backports the "lib/zlib: Set of s390 DFLTCC related patches
> for kernel zlib" series into an earlier kernel has a better way of
> knowing that a fixup is needed.
> 

Thanks,
Mikhail