Re: [PATCH RFC 0/9] lib/lz4: stop forking upstream LZ4, vendor it instead

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Sep 25, 2026 at 01:27:30PM +0200, Michal Wilczynski wrote:
> The in-kernel LZ4 is a fork. The decompressor was last synced with
> upstream v1.8.3 in 2018 and the compressor with v1.7.3 in 2017, both by
> hand. Upstream has made 488 commits against lib/ since, and the gap is
> maintained one cherry-pick at a time.
> 
> That has left real bugs in place for example the forked
> LZ4_decompress_fast() has no bounds checks, so corrupted input runs off
> the output buffer in both directions. 
> 
> This series vendors the upstream sources unmodified and adapts them at
> build time, so a re-sync becomes a directory copy:

At a high level, this looks good to me, and it's similar to what was
done with zstd.  I don't see any obvious issues with the integration.

There are disadvantages to directly integrating external projects like
this, vs. writing a small implementation from scratch for the kernel.
But the existing LZ4 code in the kernel isn't that, but rather a fork
from upstream anyway, and it's clearly not being maintained properly.

The upstream LZ4 codebase also already avoids many of the typical
incompatibilities with Linux kernel code that are often seen in
userspace projects (such as assuming FPU/SIMD/vector instructions can be
used at any time, or that the stack size is infinite, or that the C
standard library is available, or that it's reasonable to have hundreds
of files or 100MB of test data, etc.).

And writing properly optimized compression/decompression code is quite
difficult.  So yes, syncing with the latest LZ4 upstream seems like the
right choice for the kernel.

- Eric