Re: [PATCH v3] erofs: cap LZMA stream pool size

On Tue, 28 Jul 2026 at 08:55, SJ Park <[email protected]> wrote:
>
> On Tue, 28 Jul 2026 14:31:14 +0800 Gao Xiang <[email protected]> wrote:
>
> > Hi SJ,
> >
> > On Mon, Jul 27, 2026 at 08:46:32PM -0700, SJ Park wrote:
> > > Hello,
> > >
> > > On Tue, 21 Jul 2026 11:44:04 +0800 Gao Xiang <[email protected]> wrote:
> > >
> > > > Hi Machael,
> > > >
> > > > On 2026/7/17 11:43, Gao Xiang wrote:
> > > > >
> > > > >
> > > > > On 2026/7/14 19:47, Michael Bommarito wrote:
> >
> > ...
> >
> > > > >
> > > > I submitted the following version to -next:
> > > >
> > > >  From 4ec57610a769cd93027d12134c75160390b23b08 Mon Sep 17 00:00:00 2001
> > > > From: Michael Bommarito <[email protected]>
> > > > Date: Tue, 14 Jul 2026 07:47:29 -0400
> > > > Subject: erofs: cap LZMA stream pool size
> > > >
> > > > fs/erofs/decompressor_lzma.c sizes the module-global MicroLZMA stream
> > > > pool from num_possible_cpus() when the lzma_streams module parameter is
> > > > unset, then z_erofs_load_lzma_config() preallocates one image-supplied
> > > > dictionary per stream, accepting dictionaries up to 8 MiB.  On high-CPU
> > > > systems, a small EROFS image can pin hundreds of MiB of vmalloc-backed
> > > > decoder state until the erofs module is unloaded.
> > > >
> > > > Impact: An EROFS image mounted by the system can pin up to 8 MiB of
> > > > vmalloc memory per LZMA stream, either as intended or unexpectedly.
> > > >
> > > > Bound the default stream count by a new
> > > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS option, default 16, so the
> > > > worst-case default preallocation is 128 MiB if the number of CPUs is no
> > > > less than 16 while preserving the existing per-image dictionary limit.
> > > > An explicit lzma_streams module parameter is still honoured as-is, so
> > > > administrators who deliberately size the pool are not affected.
> > > >
> > > > Fixes: 622ceaddb764 ("erofs: lzma compression support")
> > > > Cc: [email protected]
> > > > Assisted-by: Claude:claude-opus-4-8
> > > > Signed-off-by: Michael Bommarito <[email protected]>
> > > > Reviewed-by: Gao Xiang <[email protected]>
> > > > Signed-off-by: Gao Xiang <[email protected]>
> > > > ---
> > > >   fs/erofs/Kconfig             | 14 ++++++++++++++
> > > >   fs/erofs/decompressor_lzma.c |  3 ++-
> > > >   2 files changed, 16 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
> > > > index 4789b1077d8ce..36f027c1c5ac5 100644
> > > > --- a/fs/erofs/Kconfig
> > > > +++ b/fs/erofs/Kconfig
> > > > @@ -131,6 +131,20 @@ config EROFS_FS_ZIP_LZMA
> > > >
> > > >             Say N if you want to disable LZMA compression support.
> > > >
> > > > +config EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS
> > > > + int "EROFS LZMA default maximum decompression streams"
> > > > + depends on EROFS_FS_ZIP_LZMA
> > > > + range 1 NR_CPUS
> > >
> > > Hello, I just found this breaks CONFIG_NR_CPUS undefined builds.  For example,
> > > my m68k build test [1] shows problems like below:
> > >
> > >     $ build_m68k_w1.sh
> > >     [...]
> > >     fs/erofs/Kconfig:137:warning: range is invalid
> > >     .config:13480:warning: symbol value 'NR_CPUS' invalid for EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS
> > >
> > > I confirmed using 1024 as the upperlimit of the range, like the original patch,
> > > fixes the problem.  I'm not sure if that's the right and preferred fix, though.
> > > I'm just reporting my finding.
> > >
> > > [1] https://github.com/damonitor/damon-tests/blob/master/corr/tests/build_m68k_w1.sh
> >
> > Thanks for the report, but may I ask if it was a warning instead of
> > a configuration failure?
>
> Indeed it didn't directly fails.  Instead, it was trying to do config again,
> like below.
>
> [...]
> fs/erofs/Kconfig:137:warning: range is invalid
> .config:13479:warning: symbol value 'NR_CPUS' invalid for EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS
> *
> * Restart config...
> *
> *
> * Miscellaneous filesystems
> *
> Miscellaneous filesystems (MISC_FILESYSTEMS) [Y/n/?] y
>   ORANGEFS (Powered by PVFS) support (ORANGEFS_FS) [Y/n/m/?] y
>   ADFS file system support (ADFS_FS) [Y/n/m/?] y
>     ADFS write support (DANGEROUS) (ADFS_FS_RW) [Y/n/?] y
> [...]
>   UFS file system support (read only) (UFS_FS) [Y/n/m/?] y
>     UFS file system write support (DANGEROUS) (UFS_FS_WRITE) [Y/n/?] y
>     UFS debugging (UFS_DEBUG) [Y/n/?] y
>   EROFS filesystem support (EROFS_FS) [Y/n/m/?] y
>     EROFS debugging feature (EROFS_FS_DEBUG) [Y/n/?] y
>     EROFS extended attributes (EROFS_FS_XATTR) [Y/n/?] y
>       EROFS Access Control Lists (EROFS_FS_POSIX_ACL) [Y/n/?] y
>       EROFS Security Labels (EROFS_FS_SECURITY) [Y/n/?] y
>     File-backed EROFS filesystem support (EROFS_FS_BACKED_BY_FILE) [Y/n/?] y
>     EROFS Data Compression Support (EROFS_FS_ZIP) [Y/n/?] y
>       EROFS LZMA compressed data support (EROFS_FS_ZIP_LZMA) [Y/n/?] y
>         EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [NR_CPUS] (NEW)
>
> And, I find no way to go out of the prompt other than Ctrl-C.
>
> > (because I didn't see a report on -next also
> > I don't have a m68k testfarm).
>
> I don't have a m68k testfarm, either.  I'm doing crossbuild [1].  Hopefully you
> could also reproduce it.

I think you can reproduce some of the issues on most architectures
with a non-SMP kernel, cfr. my reply[1] to Uwe's proposed fix.
Unfortunately the Kconfig warning only shows up on architectures that
don't define NR_CPUS (because they do not support SMP) at all,
while ending up with zero streams is probably a runtime failure.

[1] https://lore.kernel.org/CAMuHMdVGKX=3cfOrLWp1uSHX76xf1-=C0+GVCXkA8JTqNPg-ew@mail.gmail.com

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds