On Thu, Mar 20, 2025 at 09:55:42AM +0100, Ard Biesheuvel wrote: > On Thu, 20 Mar 2025 at 09:14, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, Mar 20, 2025 at 08:51:40AM +0100, Ard Biesheuvel wrote: > > > > > > IIRC Eric had some feedback at the time regarding the exact behavior > > > of the zlib API, and I notice that the code no longer deals with > > > Z_SYNC_FLUSH at all, which I did handle in my version of patch #3. > > > > I didn't see any feedback regarding this when looking at your patch: > > > > https://lore.kernel.org/linux-crypto/20230718125847.3869700-21-ardb@xxxxxxxxxx/ > > > > Do you have a link to that discussion? > > > > No. I did some digging but I could find anything. Eric might remember. I'm not sure what this is referring to. Then again this patchset doesn't apply, so it's unreviewable anyway. Just a note, for compression and decompression it's often more efficient to linearize in the caller. Otherwise the algorithm ends up having to copy the uncompressed data to an internal buffer anyway. That's needed for the match finding (compression) and match copying (decompression) to work. As I mentioned before, the "stream" terminology that Herbert is choosing for some reason also seems less than ideal. "workspace" would be better. Many of the compression algorithms don't even support streaming. > > I was going to add the original USAGI workaround but then I > > thought perhaps it is no longer necessary as our zlib has > > been updated since the workaround was added back in 2003. The kernel's zlib was forked from upstream zlib in the 90s and hasn't been re-synced since then. - Eric
