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

[SJ Park <sj@kernel.org>]

On Tue, 28 Jul 2026 14:31:14 +0800 Gao Xiang <xiang@kernel.org> 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 <hsiangkao@linux.alibaba.com> 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 <michael.bommarito@gmail.com>
> > > 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: stable@vger.kernel.org
> > > Assisted-by: Claude:claude-opus-4-8
> > > Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> > > Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> > > Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> > > ---
> > >   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.

> 
> Personally I think NR_CPU is better than an arbitrary number (like 1024)
> for sysadmins (or vendors) to customize their kernels so I hope I could
> find a way to use NR_CPUS-like approach instead of a hardcoded number.

I agree.  I have no good idea for the right fix at the moment, though.

[1] https://github.com/damonitor/damon-tests/blob/master/corr/tests/build_m68k_w1.sh


Thanks,
SJ

[...]