On Thu, Sep 17, 2026 at 11:52 PM Tom Rini <[email protected]> wrote: > > On Thu, Sep 17, 2026 at 06:02:23PM +0400, Alexey Charkov wrote: > > > SPL_ZSTD selects XXHASH, but xxhash.o is built from inside the > > ifndef CONFIG_XPL_BUILD block, so it never reaches an SPL link. zstd's > > decompressor calls xxh64_* from code that survives --gc-sections, so > > today the option only builds because nothing in SPL calls > > zstd_decompress() and the whole library is discarded. The first caller > > would fail to link. > > > > Give xxhash its own phase symbol and build rule, the way the other > > compression libraries already have, and note in the SPL_ZSTD help how > > much heap the decompressor wants, since that is the other thing which > > may stop it from working. > > > > Signed-off-by: Alexey Charkov <[email protected]> > > --- > > lib/Kconfig | 12 +++++++++++- > > lib/Makefile | 3 ++- > > 2 files changed, 13 insertions(+), 2 deletions(-) > > > > diff --git a/lib/Kconfig b/lib/Kconfig > > index 6b6b90bc915c..6e6df5b3b191 100644 > > --- a/lib/Kconfig > > +++ b/lib/Kconfig > > @@ -833,6 +833,9 @@ config CRC32C > > config XXHASH > > bool > > > > +config SPL_XXHASH > > + bool > > + > > endmenu > > > > menu "Compression Support" > > @@ -1011,10 +1014,17 @@ config TPL_ZLIB > > config SPL_ZSTD > > bool "Enable Zstandard decompression support in SPL" > > depends on SPL > > - select XXHASH > > + select SPL_XXHASH > > help > > This enables Zstandard decompression library in the SPL. > > > > + Decompression allocates a 94KB context, and nothing else: the > > + single-shot API it uses decompresses straight into the caller's > > + buffer and takes its window from there, so the compression level > > + does not change what the SPL heap has to hold. > > This is good to explain here. > > > With > > + SPL_SYS_MALLOC_SIMPLE that memory is never returned, as free() does > > + nothing there. > > This is already noted in the help text for SPL_SYS_MALLOC_SIMPLE so we > shouldn't repeat ourselves.
Alright, I'll drop this part. The reason for including it was that multiple entries into the decompression routine will leak that 94KB context each because free() is a no-op, which may cause issues for users with tighter heap space. It hasn't been a problem in my testing on Rockchip, though, as its SPL has the luxury of an MMU enabled and hundreds of megabytes of guaranteed addressable RAM. Best regards, Alexey
