On 5/14/21 12:22 PM, Linus Torvalds wrote: > On Fri, May 14, 2021 at 11:52 AM Vineet Gupta > <Vineet.Gupta1@xxxxxxxxxxxx> wrote: >> Wasn't the new zlib code slated for 5.14. I don't see it in your master yet > You're right, I never actually committed it, since it was specific to > ARC and -O3 Well, not really, the issue manifested in ARC O3 testing, but I showed the problem existed for arm64 gcc too. > and I wasn't entirely happy with the amount of testing it > got (with Heiko pointing out that the s390 stuff needed more fixes for > the change). With his addon patch everything seemed hunky dory. > The patch below is required on top of your patch to make it compile > for s390 as well. > Tested with kernel image decompression, and also btrfs with file > compression; both software and hardware compression. > Everything seems to work. > So in fact it's not even queued up for 5.14 due to this all, I just dropped it. But Why. Can't we throw it in linux-next for 5.14. I promise to test it - and will likely hit any corner cases. Also for the time being we could force just that file/files to build for -O3 to stress test the aspects that were fragile. >>> and the biggy >>> case didn't even use "get_unaligned()"). >> Indeed this series is sort of orthogonal to that bug, but IMO that bug >> still exists in 5.13 for -O3 build, granted that is not enabled for !ARC. > Right, the zlib bug is still there. > > But Arnd's series wouldn't even fix it: right now inffast has its own > - ugly and slow - special 2-byte-only version of "get_unaligned()", > called "get_unaligned16()". I know that's why said they are orthogonal. > And because it's ugly and slow, it's not actually used for > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. > > Vineet - maybe the fix is to not take my patch to update to a newer > zlib, but to just fix inffast to use the proper get_unaligned(). Then > Arnd's series _would_ actually fix all this.. OK if you say so. -Vineet
