linux-kernel - Re: [PATCH v2 2/2] kbuild: pass --stream-size --no-content-size to zstd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Dec 2021 07:52:43 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>
Cc:     Michael Forney <forney@...gle.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nick Terrell <terrelln@...com>, Ingo Molnar <mingo@...nel.org>,
        Sedat Dilek <sedat.dilek@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] kbuild: pass --stream-size --no-content-size to zstd

On Thu, Nov 25, 2021 at 12:30 AM Alex Xu (Hello71) <alex_y_xu@...oo.ca> wrote:
>
> Otherwise, it allocates 2 GB of memory at once. Even though the majority
> of this memory is never touched, the default heuristic overcommit
> refuses this request if less than 2 GB of RAM+swap is currently
> available. This results in "zstd: error 11 : Allocation error : not
> enough memory" and the kernel failing to build.
>
> When the size is specified, zstd will reduce the memory request
> appropriately. For typical kernel sizes of ~32 MB, the largest mmap
> request will be reduced to 512 MB, which will succeed on all but the
> smallest devices.
>
> For inputs around this size, --stream-size --no-content-size may
> slightly decrease the compressed size, or slightly increase it:
> https://github.com/facebook/zstd/issues/2848.
>
> Signed-off-by: Alex Xu (Hello71) <alex_y_xu@...oo.ca>




The reason why we need this workaround is just because we do
"cat and compress".  zstd must allocate a huge memory beforehand
since it cannot predict how long the stream it will receive.

If zstd is given with a file name, it can fstat it to know its file size
and allocate the minimal amount of memory.


This is my test.
I used 'ulimit' to set the upper limit of the memory the zstd can use.


[test steps]

  # Create a 1kB file
  $ truncate --size=1k dummy

  # Set the memory size limit to 10MB
  $ ulimit -S -v 10240

  # Pass the file as a argument; success
  $ zstd -19 -o dummy.zst dummy
  dummy                :  2.15%   (  1024 =>     22 bytes, dummy.zst)

  # cat and zstd; fail
  $ cat dummy | zstd -19 > dummy.zst
  zstd: error 11 : Allocation error : not enough memory

  # cat and zstd --stream-size; success
  $ cat dummy | zstd -19 --stream-size=1024 > dummy.zst




scripts/Makefile.modinst was written in such a way
that zstd can know the file size by itself.

      cmd_zstd = $(ZSTD) -T0 --rm -f -q $<


We cannot rewrite scripts/Makefile.lib in that way because
arch/x86/boot/compress/Makefile concatenates two files before
compression. And this is the only use-case of this feature.

So, I am seriously considering to revert this commit:

commit d3dd3b5a29bb9582957451531fed461628dfc834
Author: H. Peter Anvin <hpa@...or.com>
Date:   Tue May 5 21:17:15 2009 -0700

    kbuild: allow compressors (gzip, bzip2, lzma) to take multiple inputs




With that commit reverted, zstd will take a single input file,
and we can do "zstd -o <output> <input>".


So, I will take some time to investigate that approach.




> ---
>  scripts/Makefile.lib | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index ca901814986a..c98a82ca38e6 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -466,12 +466,20 @@ quiet_cmd_xzmisc = XZMISC  $@
>  # single pass, so zstd doesn't need to allocate a window buffer. When streaming
>  # decompression is used, like initramfs decompression, zstd22 should likely not
>  # be used because it would require zstd to allocate a 128 MB buffer.
> +#
> +# --stream-size to reduce zstd memory usage (otherwise zstd -22 --ultra
> +# allocates, but does not use, 2 GB) and potentially improve compression.
> +#
> +# --no-content-size to save three bytes which we do not use (we use size_append).
> +
> +# zstd --stream-size is only supported since 1.4.4
> +zstd_stream_size = $(shell $(ZSTD) -1c --stream-size=0 --no-content-size </dev/null >/dev/null 2>&1 && printf '%s' '--stream-size=$(total_size) --no-content-size')
>
>  quiet_cmd_zstd = ZSTD    $@
> -      cmd_zstd = { cat $(real-prereqs) | $(ZSTD) -19; $(size_append); } > $@
> +      cmd_zstd = { cat $(real-prereqs) | $(ZSTD) $(zstd_stream_size) -19; $(size_append); } > $@
>
>  quiet_cmd_zstd22 = ZSTD22  $@
> -      cmd_zstd22 = { cat $(real-prereqs) | $(ZSTD) -22 --ultra; $(size_append); } > $@
> +      cmd_zstd22 = { cat $(real-prereqs) | $(ZSTD) $(zstd_stream_size) -22 --ultra; $(size_append); } > $@
>
>  # ASM offsets
>  # ---------------------------------------------------------------------------
> --
> 2.34.0
>


-- 
Best Regards
Masahiro Yamada