Message-ID: <95f018c8-aad9-3c5a-7193-7187dd1a85e5@linux.ibm.com>
Date:   Tue, 28 Feb 2023 10:50:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: [PATCH 1/1] lib/zlib: DFLTCC deflate does not write all available
 bits for Z_NO_FLUSH
Content-Language: en-US
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Heiko Carstens <hca@linux.ibm.com>,
        Vasily Gorbik <gor@linux.ibm.com>,
        LKML <linux-kernel@vger.kernel.org>
References: <20230221131617.3369978-1-zaslonko@linux.ibm.com>
 <20230221131617.3369978-2-zaslonko@linux.ibm.com>
 <20230223125402.2d9fa0465ed62410dd5b4ed9@linux-foundation.org>
From:   Zaslonko Mikhail <zaslonko@linux.ibm.com>
In-Reply-To: <20230223125402.2d9fa0465ed62410dd5b4ed9@linux-foundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Precedence: bulk

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