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

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? (because I didn't see a report on -next also
I don't have a m68k testfarm).

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.

Also I've seen the previous discussion to define CONFIG_NR_CPUS on m68k
but not sure what happened in the end:
https://lore.kernel.org/r/[email protected]

Thanks,
Gao Xiang

> 
> 
> Thanks,
> SJ
> 
> [...]