[PATCH v3] erofs: cap LZMA stream pool size

[PATCH v3] erofs: cap LZMA stream pool size

[Michael Bommarito]

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 attacker-supplied EROFS image mounted by the system can pin up
to 8 MiB times the LZMA stream count of kernel vmalloc memory.

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 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>
---
v3: rename the Kconfig option to EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS
    and only cap the default (num_possible_cpus); an explicit non-zero
    lzma_streams module parameter is now honoured unchanged.  Simplified
    the Kconfig help text and dropped the in-code comment, per Gao
    Xiang's review.
v2: https://lore.kernel.org/linux-erofs/20260711143419.2762894-1-michael.bommarito@gmail.com/

Evidence: the stock code sets the stream count to num_possible_cpus() when
lzma_streams is unset, and z_erofs_load_lzma_config() then preallocates one
image-supplied dictionary (up to Z_EROFS_LZMA_MAX_DICT_SIZE, 8 MiB) per
stream, so on a host with many CPUs a single small mounted image reserves
num_possible_cpus() x up-to-8 MiB of vmalloc decoder state until the module
is unloaded.  With this patch an unset lzma_streams caps the default at
CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS (16, i.e. 128 MiB worst case),
while an explicit non-zero lzma_streams= is left unbounded.  Built with W=1,
no new warnings; boots and mounts an LZMA image with the capped default and
with lzma_streams= overriding it.

 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..8948cb6314e07 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 1024
+	default 16
+	help
+	  By default EROFS allocates one LZMA decompression stream per CPU.
+	  Each stream can hold a dictionary of up to 8 MiB taken from the
+	  mounted image, so on systems with many CPUs this can reserve a lot
+	  of memory.  This caps the default; the lzma_streams module parameter
+	  still overrides it.
+
+	  If unsure, keep the default of 16.
+
 config EROFS_FS_ZIP_DEFLATE
 	bool "EROFS DEFLATE compressed data support"
 	depends on EROFS_FS_ZIP
diff --git a/fs/erofs/decompressor_lzma.c b/fs/erofs/decompressor_lzma.c
index f6692d0f2f04d..6b0cdb446c6ad 100644
--- a/fs/erofs/decompressor_lzma.c
+++ b/fs/erofs/decompressor_lzma.c
@@ -51,7 +51,8 @@ static int __init z_erofs_lzma_init(void)
 
 	/* by default, use # of possible CPUs instead */
 	if (!z_erofs_lzma_nstrms)
-		z_erofs_lzma_nstrms = num_possible_cpus();
+		z_erofs_lzma_nstrms = min_t(unsigned int, num_possible_cpus(),
+				CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS);
 
 	for (i = 0; i < z_erofs_lzma_nstrms; ++i) {
 		struct z_erofs_lzma *strm = kzalloc_obj(*strm);
-- 
2.53.0

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

[Gao Xiang]

On 2026/7/14 19:47, Michael Bommarito wrote:
> 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 attacker-supplied EROFS image mounted by the system can pin up
> to 8 MiB times the LZMA stream count of kernel vmalloc memory.
> 
> 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 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>

Thanks,
Gao Xiang

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

[Gao Xiang]

Hi Machael,

On 2026/7/17 11:43, Gao Xiang wrote:
> 
> 
> On 2026/7/14 19:47, Michael Bommarito wrote:
>> 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 attacker-supplied EROFS image mounted by the system can pin up
>> to 8 MiB times the LZMA stream count of kernel vmalloc memory.
>>
>> 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 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>
> 
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
+	default 16
+	help
+	  By default EROFS allocates one LZMA decompression stream per CPU.
+	  Each stream can hold a dictionary of up to 8 MiB taken from the
+	  mounted image, so on systems with many CPUs this can reserve a lot
+	  of memory.  This caps the default; the lzma_streams module parameter
+	  still overrides it.
+
+	  If unsure, keep the default of 16.
+
  config EROFS_FS_ZIP_DEFLATE
  	bool "EROFS DEFLATE compressed data support"
  	depends on EROFS_FS_ZIP
diff --git a/fs/erofs/decompressor_lzma.c b/fs/erofs/decompressor_lzma.c
index f6692d0f2f04d..6b0cdb446c6ad 100644
--- a/fs/erofs/decompressor_lzma.c
+++ b/fs/erofs/decompressor_lzma.c
@@ -51,7 +51,8 @@ static int __init z_erofs_lzma_init(void)
  
  	/* by default, use # of possible CPUs instead */
  	if (!z_erofs_lzma_nstrms)
-		z_erofs_lzma_nstrms = num_possible_cpus();
+		z_erofs_lzma_nstrms = min_t(unsigned int, num_possible_cpus(),
+				CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS);
  
  	for (i = 0; i < z_erofs_lzma_nstrms; ++i) {
  		struct z_erofs_lzma *strm = kzalloc_obj(*strm);
-- 

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

[SJ Park]

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:
> >> 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 attacker-supplied EROFS image mounted by the system can pin up
> >> to 8 MiB times the LZMA stream count of kernel vmalloc memory.
> >>
> >> 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 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>
> > 
> 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,
SJ

[...]

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

[Gao Xiang]

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? (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/20240923235617.1584056-1-linux@roeck-us.net

Thanks,
Gao Xiang

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

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

[SJ Park]

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

[...]

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

[Geert Uytterhoeven]

On Tue, 28 Jul 2026 at 08:55, SJ Park <sj@kernel.org> wrote:
>
> 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.

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 -- geert@linux-m68k.org

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

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]

Hello,

On Mon, Aug 03, 2026 at 10:09:06AM +0200, Geert Uytterhoeven wrote:
> On Tue, 28 Jul 2026 at 08:55, SJ Park <sj@kernel.org> wrote:
> > I don't have a m68k testfarm, either.  I'm doing crossbuild [1].  Hopefully you
> > could also reproduce it.

FTR, I don't have m68k hardware either, but as this is a build time
failure installing the Debian package gcc-m68k-linux-gnu and then doing
builds using

	make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu-

is good enough to reproduce the failure.

> 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

I guess EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS should depend on SMP and
it's use should be conditionalized using something like

diff --git a/fs/erofs/decompressor_lzma.c b/fs/erofs/decompressor_lzma.c
index 6b0cdb446c6a..c00e94f8206f 100644
--- a/fs/erofs/decompressor_lzma.c
+++ b/fs/erofs/decompressor_lzma.c
@@ -50,9 +50,13 @@ static int __init z_erofs_lzma_init(void)
 	unsigned int i;
 
 	/* by default, use # of possible CPUs instead */
-	if (!z_erofs_lzma_nstrms)
-		z_erofs_lzma_nstrms = min_t(unsigned int, num_possible_cpus(),
-				CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS);
+	if (!z_erofs_lzma_nstrms) {
+		if (IS_ENABLED(CONFIG_SMP))
+			z_erofs_lzma_nstrms = min_t(unsigned int, num_possible_cpus(),
+					CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS);
+		else
+			z_erofs_lzma_nstrms = 1;
+	}
 
 	for (i = 0; i < z_erofs_lzma_nstrms; ++i) {
 		struct z_erofs_lzma *strm = kzalloc_obj(*strm);

I played a bit with the definition of
EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS in fs/erofs/Kconfig, but didn't
find a way to define it that both uses NR_CPUS and doesn't generate a
warning with ARCH=m68k.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Geert Uytterhoeven]

On Mon, 3 Aug 2026 at 11:12, Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
> On Mon, Aug 03, 2026 at 10:09:06AM +0200, Geert Uytterhoeven wrote:
> > On Tue, 28 Jul 2026 at 08:55, SJ Park <sj@kernel.org> wrote:
> > > I don't have a m68k testfarm, either.  I'm doing crossbuild [1].  Hopefully you
> > > could also reproduce it.
>
> FTR, I don't have m68k hardware either, but as this is a build time
> failure installing the Debian package gcc-m68k-linux-gnu and then doing
> builds using
>
>         make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu-
>
> is good enough to reproduce the failure.
>
> > 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
>
> I guess EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS should depend on SMP and
> it's use should be conditionalized using something like
>
> diff --git a/fs/erofs/decompressor_lzma.c b/fs/erofs/decompressor_lzma.c
> index 6b0cdb446c6a..c00e94f8206f 100644
> --- a/fs/erofs/decompressor_lzma.c
> +++ b/fs/erofs/decompressor_lzma.c
> @@ -50,9 +50,13 @@ static int __init z_erofs_lzma_init(void)
>         unsigned int i;
>
>         /* by default, use # of possible CPUs instead */
> -       if (!z_erofs_lzma_nstrms)
> -               z_erofs_lzma_nstrms = min_t(unsigned int, num_possible_cpus(),
> -                               CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS);
> +       if (!z_erofs_lzma_nstrms) {
> +               if (IS_ENABLED(CONFIG_SMP))
> +                       z_erofs_lzma_nstrms = min_t(unsigned int, num_possible_cpus(),
> +                                       CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS);
> +               else
> +                       z_erofs_lzma_nstrms = 1;
> +       }
>
>         for (i = 0; i < z_erofs_lzma_nstrms; ++i) {
>                 struct z_erofs_lzma *strm = kzalloc_obj(*strm);

LGTM.

>
> I played a bit with the definition of
> EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS in fs/erofs/Kconfig, but didn't
> find a way to define it that both uses NR_CPUS and doesn't generate a
> warning with ARCH=m68k.

Any progress with fixing this for v7.2?

NR_CPUS depends on SMP on most architectures, so you get e.g.
with ARCH=arm allmodconfig + CONFIG_SMP=n:

    CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=0

X86 defines NR_CPUS unconditionally, so there it works as expected.
Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

[Guenter Roeck]

On 8/11/26 12:27, Geert Uytterhoeven wrote:
> On Mon, 3 Aug 2026 at 11:12, Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
>> On Mon, Aug 03, 2026 at 10:09:06AM +0200, Geert Uytterhoeven wrote:
>>> On Tue, 28 Jul 2026 at 08:55, SJ Park <sj@kernel.org> wrote:
>>>> I don't have a m68k testfarm, either.  I'm doing crossbuild [1].  Hopefully you
>>>> could also reproduce it.
>>
>> FTR, I don't have m68k hardware either, but as this is a build time
>> failure installing the Debian package gcc-m68k-linux-gnu and then doing
>> builds using
>>
>>          make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu-
>>
>> is good enough to reproduce the failure.
>>
>>> 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
>>
>> I guess EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS should depend on SMP and
>> it's use should be conditionalized using something like
>>
>> diff --git a/fs/erofs/decompressor_lzma.c b/fs/erofs/decompressor_lzma.c
>> index 6b0cdb446c6a..c00e94f8206f 100644
>> --- a/fs/erofs/decompressor_lzma.c
>> +++ b/fs/erofs/decompressor_lzma.c
>> @@ -50,9 +50,13 @@ static int __init z_erofs_lzma_init(void)
>>          unsigned int i;
>>
>>          /* by default, use # of possible CPUs instead */
>> -       if (!z_erofs_lzma_nstrms)
>> -               z_erofs_lzma_nstrms = min_t(unsigned int, num_possible_cpus(),
>> -                               CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS);
>> +       if (!z_erofs_lzma_nstrms) {
>> +               if (IS_ENABLED(CONFIG_SMP))
>> +                       z_erofs_lzma_nstrms = min_t(unsigned int, num_possible_cpus(),
>> +                                       CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS);
>> +               else
>> +                       z_erofs_lzma_nstrms = 1;
>> +       }
>>
>>          for (i = 0; i < z_erofs_lzma_nstrms; ++i) {
>>                  struct z_erofs_lzma *strm = kzalloc_obj(*strm);
> 
> LGTM.
> 
>>
>> I played a bit with the definition of
>> EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS in fs/erofs/Kconfig, but didn't
>> find a way to define it that both uses NR_CPUS and doesn't generate a
>> warning with ARCH=m68k.
> 
> Any progress with fixing this for v7.2?
> 
> NR_CPUS depends on SMP on most architectures, so you get e.g.
> with ARCH=arm allmodconfig + CONFIG_SMP=n:
> 
>      CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=0
> 
> X86 defines NR_CPUS unconditionally, so there it works as expected.
> Thanks!
> 
FWIW, m68k:allmodconfig now fails to build due to this problem all the
way back to v6.6.y.

Guenter

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

[Michael Bommarito]

On Tue, Aug 11, 2026 at 3:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > Any progress with fixing this for v7.2?

I would like to fix this since I started the problem with the original
patch, but I feel a bit stuck.  My v1 and v2 patches would not have
triggered the build failure, but Gao made valid points about the
trade-offs that led us to this v3.  Maybe it would be worth your
opinion on the config approach in those earlier patches?

Thanks,
Mike

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

[Gao Xiang]

Hi,

On Tue, Aug 11, 2026 at 03:37:38PM -0400, Michael Bommarito wrote:
> On Tue, Aug 11, 2026 at 3:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > Any progress with fixing this for v7.2?
> 
> I would like to fix this since I started the problem with the original
> patch, but I feel a bit stuck.  My v1 and v2 patches would not have
> triggered the build failure, but Gao made valid points about the
> trade-offs that led us to this v3.  Maybe it would be worth your
> opinion on the config approach in those earlier patches?
> 

Sorry about the late reply.

As I said, I really dislike hardcoded range, but it is an issue that no
NR_CPUS definition on CONFIG_SMP:

I wonder if the following diff resolves the m68k issue (I'm not an
Kconfig expert but it seems to work on x86_64 !CONFIG_SMP):

diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
index 8ca1767dafb6..2dfc313588d2 100644
--- a/fs/erofs/Kconfig
+++ b/fs/erofs/Kconfig
@@ -134,7 +134,8 @@ config EROFS_FS_ZIP_LZMA
 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
+	range 1 NR_CPUS if SMP
+	range 1 1 if !SMP
 	default 16
 	help
 	  By default EROFS allocates one LZMA decompression stream per CPU.

Thanks,
Gao Xiang

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

[Geert Uytterhoeven]

Hi Gao,

On Wed, 12 Aug 2026 at 01:37, Gao Xiang <xiang@kernel.org> wrote:
> On Tue, Aug 11, 2026 at 03:37:38PM -0400, Michael Bommarito wrote:
> > On Tue, Aug 11, 2026 at 3:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > > Any progress with fixing this for v7.2?
> >
> > I would like to fix this since I started the problem with the original
> > patch, but I feel a bit stuck.  My v1 and v2 patches would not have
> > triggered the build failure, but Gao made valid points about the
> > trade-offs that led us to this v3.  Maybe it would be worth your
> > opinion on the config approach in those earlier patches?
>
> Sorry about the late reply.
>
> As I said, I really dislike hardcoded range, but it is an issue that no
> NR_CPUS definition on CONFIG_SMP:
>
> I wonder if the following diff resolves the m68k issue (I'm not an
> Kconfig expert but it seems to work on x86_64 !CONFIG_SMP):
>
> diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
> index 8ca1767dafb6..2dfc313588d2 100644
> --- a/fs/erofs/Kconfig
> +++ b/fs/erofs/Kconfig
> @@ -134,7 +134,8 @@ config EROFS_FS_ZIP_LZMA
>  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
> +       range 1 NR_CPUS if SMP
> +       range 1 1 if !SMP
>         default 16
>         help
>           By default EROFS allocates one LZMA decompression stream per CPU.

Thank you, that seems to work (despite still seeing the warning on m68k,
as NR_CPUS does not exist).

Test runs on ARM (NR_CPUS depends on SMP, like most architectures), m68k
(no CONFIG_NR_CPUS), and x86 (NR_CPUS is always defined) before/after:

     $ make ARCH=arm allmodconfig
     $ grep CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS .config
     CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=4

 SMP is OK.

     $ sed -i "/CONFIG_SMP=y/d" .config
     $ yes "" | make ARCH=arm oldconfig
-
-No warning...
-
     $ grep CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS .config
-    CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=0
+    CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1

-... but automatic configuration is silently broken on UP.
+UP is OK with automatic configuration.

     $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config
     $ yes "" | make ARCH=arm oldconfig
-            EROFS LZMA default maximum decompression streams
(EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW)
-    [infinite loop]
+    $ grep CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS .config
+    CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1

-Manual configuration is broken.
+UP is OK with manual configuration.

 --------------------------------------------------------------------------------

      $ make ARCH=m68k allmodconfig
     fs/erofs/Kconfig:137:warning: range is invalid

 Warning...

     $ grep CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS .config
-    CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=NR_CPUS
-
-... but this will actually build and work, as <linux/threads.h> has:
-
-    #ifndef CONFIG_NR_CPUS
-    /* FIXME: This should be fixed in the arch's Kconfig */
-    #define CONFIG_NR_CPUS  1
-    #endif
-
-    /* Places which use this should consider cpumask_var_t. */
-    #define NR_CPUS         CONFIG_NR_CPUS
+    CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1
+
+... but UP is OK with automatic configuration.

     $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config
     $ yes "" | make ARCH=m68k oldconfig
-            EROFS LZMA default maximum decompression streams
(EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [NR_CPUS] (NEW)
-    [infinite loop]
+    fs/erofs/Kconfig:137:warning: range is invalid
+
+Warning...
+
+    $ grep CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS .config
+    CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1

-Manual configuration is broken.
+... but UP is OK with manual configuration.

 --------------------------------------------------------------------------------

     $ make ARCH=x86 allmodconfig
     $ grep CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS .config
     CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=16

 SMP is OK.

     $ sed -i "/CONFIG_SMP=y/d" .config
     $ yes "" | make ARCH=x86 oldconfig
     $ grep CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS .config
     CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1

 UP is OK with automatic configuration.

     $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config
     $ yes "" | make ARCH=x86 oldconfig
     $ grep CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS .config
     CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1

 UP is OK with manual configuration.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

[Gao Xiang]

Hi Geert,

On Wed, Aug 12, 2026 at 11:30:14AM +0200, Geert Uytterhoeven wrote:
> Hi Gao,
> 
> On Wed, 12 Aug 2026 at 01:37, Gao Xiang <xiang@kernel.org> wrote:
> > On Tue, Aug 11, 2026 at 03:37:38PM -0400, Michael Bommarito wrote:
> > > On Tue, Aug 11, 2026 at 3:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > Any progress with fixing this for v7.2?
> > >
> > > I would like to fix this since I started the problem with the original
> > > patch, but I feel a bit stuck.  My v1 and v2 patches would not have
> > > triggered the build failure, but Gao made valid points about the
> > > trade-offs that led us to this v3.  Maybe it would be worth your
> > > opinion on the config approach in those earlier patches?
> >
> > Sorry about the late reply.
> >
> > As I said, I really dislike hardcoded range, but it is an issue that no
> > NR_CPUS definition on CONFIG_SMP:
> >
> > I wonder if the following diff resolves the m68k issue (I'm not an
> > Kconfig expert but it seems to work on x86_64 !CONFIG_SMP):
> >
> > diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
> > index 8ca1767dafb6..2dfc313588d2 100644
> > --- a/fs/erofs/Kconfig
> > +++ b/fs/erofs/Kconfig
> > @@ -134,7 +134,8 @@ config EROFS_FS_ZIP_LZMA
> >  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
> > +       range 1 NR_CPUS if SMP
> > +       range 1 1 if !SMP
> >         default 16
> >         help
> >           By default EROFS allocates one LZMA decompression stream per CPU.
> 
> Thank you, that seems to work (despite still seeing the warning on m68k,
> as NR_CPUS does not exist).
> 

...

> 
>       $ make ARCH=m68k allmodconfig
>      fs/erofs/Kconfig:137:warning: range is invalid
> 
>  Warning...
>

Yes, other arches shouldn't have the warning because I think other
arches (including microblaze) defines NR_CPUS in Kconfig, except m68k.

The following diff can eliminate the m68k warning above, I think m68k
folks could consider this way if you really don't want to define an
explicit NR_CPUS.  Anyway, I think it should go with another patch:

```
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 11835eb59d94..90499f126c73 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -44,6 +44,9 @@ config M68K
 	select UACCESS_MEMCPY if !MMU
 	select ZONE_DMA
 
+config NR_CPUS
+	int
+
 config CPU_BIG_ENDIAN
 	def_bool y
```

I will try to form a formal patch (with the diff in the previous reply)
directly to Linus (since I don't have other urgent patches for
Linux 7.2.)

Thanks,
Gao Xiang 

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

[Geert Uytterhoeven]

Hi Gao,

On Wed, 12 Aug 2026 at 12:55, Gao Xiang <xiang@kernel.org> wrote:
>
> Hi Geert,
>
> On Wed, Aug 12, 2026 at 11:30:14AM +0200, Geert Uytterhoeven wrote:
> > Hi Gao,
> >
> > On Wed, 12 Aug 2026 at 01:37, Gao Xiang <xiang@kernel.org> wrote:
> > > On Tue, Aug 11, 2026 at 03:37:38PM -0400, Michael Bommarito wrote:
> > > > On Tue, Aug 11, 2026 at 3:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > > Any progress with fixing this for v7.2?
> > > >
> > > > I would like to fix this since I started the problem with the original
> > > > patch, but I feel a bit stuck.  My v1 and v2 patches would not have
> > > > triggered the build failure, but Gao made valid points about the
> > > > trade-offs that led us to this v3.  Maybe it would be worth your
> > > > opinion on the config approach in those earlier patches?
> > >
> > > Sorry about the late reply.
> > >
> > > As I said, I really dislike hardcoded range, but it is an issue that no
> > > NR_CPUS definition on CONFIG_SMP:
> > >
> > > I wonder if the following diff resolves the m68k issue (I'm not an
> > > Kconfig expert but it seems to work on x86_64 !CONFIG_SMP):
> > >
> > > diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
> > > index 8ca1767dafb6..2dfc313588d2 100644
> > > --- a/fs/erofs/Kconfig
> > > +++ b/fs/erofs/Kconfig
> > > @@ -134,7 +134,8 @@ config EROFS_FS_ZIP_LZMA
> > >  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
> > > +       range 1 NR_CPUS if SMP
> > > +       range 1 1 if !SMP
> > >         default 16
> > >         help
> > >           By default EROFS allocates one LZMA decompression stream per CPU.
> >
> > Thank you, that seems to work (despite still seeing the warning on m68k,
> > as NR_CPUS does not exist).
> >
>
> ...
>
> >
> >       $ make ARCH=m68k allmodconfig
> >      fs/erofs/Kconfig:137:warning: range is invalid
> >
> >  Warning...
> >
>
> Yes, other arches shouldn't have the warning because I think other
> arches (including microblaze) defines NR_CPUS in Kconfig, except m68k.
>
> The following diff can eliminate the m68k warning above, I think m68k
> folks could consider this way if you really don't want to define an
> explicit NR_CPUS.  Anyway, I think it should go with another patch:
>
> ```
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 11835eb59d94..90499f126c73 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -44,6 +44,9 @@ config M68K
>         select UACCESS_MEMCPY if !MMU
>         select ZONE_DMA
>
> +config NR_CPUS
> +       int
> +

Let's bite the issue on m68k for good, I'll take Uwe's patch for v7.2
https://lore.kernel.org/all/20260731094950.1988084-2-ukleinek@kernel.org

>  config CPU_BIG_ENDIAN
>         def_bool y
> ```
>
> I will try to form a formal patch (with the diff in the previous reply)
> directly to Linus (since I don't have other urgent patches for
> Linux 7.2.)

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

[PATCH] erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms

[Gao Xiang]

CONFIG_NR_CPUS doesn't define on some UP platforms (e.g. arm), so this
can cause make oldconfig to loop indefinitely when CONFIG_SMP=n:

 $ make ARCH=arm allmodconfig
 $ sed -i "/CONFIG_SMP=y/d" .config
 $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config

EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW)
EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW)
...

Let's guard NR_CPUS with SMP instead of using a hardcoded arbitrary CPU
uplimit here, similar to commit a3344078101c ("mm: make SPLIT_PTE_PTLOCKS
depend on SMP").

The initial report from SJ Park was for m68k [1] (m68k is the only arch
without NR_CPUS in Kconfig), and it will be changed in another patch [2].

[1] https://lore.kernel.org/all/anuyFHLUGDjZWY4K@XiangdeMacBook-Pro.local/T/#u
[2] https://lore.kernel.org/r/20260731094950.1988084-2-ukleinek@kernel.org

Reported-by: SJ Park <sj@kernel.org>
Closes: https://lore.kernel.org/r/20260728065447.91511-1-sj@kernel.org
Reported-by: Guenter Roeck <groeck7@gmail.com>
Closes: https://lore.kernel.org/r/87853c96-cc8f-49e6-81b1-02bfe409e372@roeck-us.net
Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size")
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Gao Xiang <xiang@kernel.org>
---
Hi Linus,

Could you apply this Kconfig fix directly since I don't have other urgent
patch for 7.2 (so maybe it's unnecessary to have a pull request just for
this..)

Many thank,
Gao Xiang

 fs/erofs/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
index 8ca1767dafb6..2dfc313588d2 100644
--- a/fs/erofs/Kconfig
+++ b/fs/erofs/Kconfig
@@ -134,7 +134,8 @@ config EROFS_FS_ZIP_LZMA
 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
+	range 1 NR_CPUS if SMP
+	range 1 1 if !SMP
 	default 16
 	help
 	  By default EROFS allocates one LZMA decompression stream per CPU.
-- 
2.47.3

Re: [PATCH] erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms

[Geert Uytterhoeven]

Hi Gao,

Thanks for your patch!

On Wed, 12 Aug 2026 at 15:12, Gao Xiang <xiang@kernel.org> wrote:
> CONFIG_NR_CPUS doesn't define on some UP platforms (e.g. arm), so this
> can cause make oldconfig to loop indefinitely when CONFIG_SMP=n:
>
>  $ make ARCH=arm allmodconfig
>  $ sed -i "/CONFIG_SMP=y/d" .config
>  $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config
>
> EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW)
> EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW)
> ...

This also fixes EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS silently becoming
zero (and thus breaking decompression completely?) for "automatic"
configs like "make allmodconfig" or "make olddefconfig" on architectures
where NR_CPUS depends on SMP (which is most of them).

>
> Let's guard NR_CPUS with SMP instead of using a hardcoded arbitrary CPU
> uplimit here, similar to commit a3344078101c ("mm: make SPLIT_PTE_PTLOCKS
> depend on SMP").
>
> The initial report from SJ Park was for m68k [1] (m68k is the only arch
> without NR_CPUS in Kconfig), and it will be changed in another patch [2].
>
> [1] https://lore.kernel.org/all/anuyFHLUGDjZWY4K@XiangdeMacBook-Pro.local/T/#u
> [2] https://lore.kernel.org/r/20260731094950.1988084-2-ukleinek@kernel.org
>
> Reported-by: SJ Park <sj@kernel.org>
> Closes: https://lore.kernel.org/r/20260728065447.91511-1-sj@kernel.org
> Reported-by: Guenter Roeck <groeck7@gmail.com>
> Closes: https://lore.kernel.org/r/87853c96-cc8f-49e6-81b1-02bfe409e372@roeck-us.net
> Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size")
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Gao Xiang <xiang@kernel.org>

Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>

> --- a/fs/erofs/Kconfig
> +++ b/fs/erofs/Kconfig
> @@ -134,7 +134,8 @@ config EROFS_FS_ZIP_LZMA
>  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
> +       range 1 NR_CPUS if SMP
> +       range 1 1 if !SMP
>         default 16
>         help
>           By default EROFS allocates one LZMA decompression stream per CPU.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [PATCH] erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms

[Gao Xiang]

Hi Geert,

On Wed, Aug 12, 2026 at 03:34:58PM +0200, Geert Uytterhoeven wrote:
> Hi Gao,
> 
> Thanks for your patch!
> 
> On Wed, 12 Aug 2026 at 15:12, Gao Xiang <xiang@kernel.org> wrote:
> > CONFIG_NR_CPUS doesn't define on some UP platforms (e.g. arm), so this
> > can cause make oldconfig to loop indefinitely when CONFIG_SMP=n:
> >
> >  $ make ARCH=arm allmodconfig
> >  $ sed -i "/CONFIG_SMP=y/d" .config
> >  $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config
> >
> > EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW)
> > EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW)
> > ...
> 
> This also fixes EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS silently becoming
> zero (and thus breaking decompression completely?) for "automatic"
> configs like "make allmodconfig" or "make olddefconfig" on architectures
> where NR_CPUS depends on SMP (which is most of them).

Yeah, unfortunately..

> 
> >

...

> >
> > Reported-by: SJ Park <sj@kernel.org>
> > Closes: https://lore.kernel.org/r/20260728065447.91511-1-sj@kernel.org
> > Reported-by: Guenter Roeck <groeck7@gmail.com>
> > Closes: https://lore.kernel.org/r/87853c96-cc8f-49e6-81b1-02bfe409e372@roeck-us.net
> > Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size")
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Signed-off-by: Gao Xiang <xiang@kernel.org>
> 
> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>

Thanks!

Thanks,
Gao Xiang

> 
> > --- a/fs/erofs/Kconfig
> > +++ b/fs/erofs/Kconfig
> > @@ -134,7 +134,8 @@ config EROFS_FS_ZIP_LZMA
> >  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
> > +       range 1 NR_CPUS if SMP
> > +       range 1 1 if !SMP
> >         default 16
> >         help
> >           By default EROFS allocates one LZMA decompression stream per CPU.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> 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
> 

Re: [PATCH] erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms

[SJ Park]

On Wed, 12 Aug 2026 21:11:43 +0800 Gao Xiang <xiang@kernel.org> wrote:

> CONFIG_NR_CPUS doesn't define on some UP platforms (e.g. arm), so this
> can cause make oldconfig to loop indefinitely when CONFIG_SMP=n:
> 
>  $ make ARCH=arm allmodconfig
>  $ sed -i "/CONFIG_SMP=y/d" .config
>  $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config
> 
> EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW)
> EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW)
> ...
> 
> Let's guard NR_CPUS with SMP instead of using a hardcoded arbitrary CPU
> uplimit here, similar to commit a3344078101c ("mm: make SPLIT_PTE_PTLOCKS
> depend on SMP").
> 
> The initial report from SJ Park was for m68k [1] (m68k is the only arch
> without NR_CPUS in Kconfig), and it will be changed in another patch [2].

Thank you for this patch.  I confirmed this fixes the issue on my setup.

> 
> [1] https://lore.kernel.org/all/anuyFHLUGDjZWY4K@XiangdeMacBook-Pro.local/T/#u
> [2] https://lore.kernel.org/r/20260731094950.1988084-2-ukleinek@kernel.org
> 
> Reported-by: SJ Park <sj@kernel.org>
> Closes: https://lore.kernel.org/r/20260728065447.91511-1-sj@kernel.org
> Reported-by: Guenter Roeck <groeck7@gmail.com>
> Closes: https://lore.kernel.org/r/87853c96-cc8f-49e6-81b1-02bfe409e372@roeck-us.net
> Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size")
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Gao Xiang <xiang@kernel.org>

Tested-by: SJ Park <sj@kernel.org>


Thanks,
SJ

[...]

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

[Guenter Roeck]

On 8/12/26 03:54, Gao Xiang wrote:
> Hi Geert,
> 
> On Wed, Aug 12, 2026 at 11:30:14AM +0200, Geert Uytterhoeven wrote:
>> Hi Gao,
>>
>> On Wed, 12 Aug 2026 at 01:37, Gao Xiang <xiang@kernel.org> wrote:
>>> On Tue, Aug 11, 2026 at 03:37:38PM -0400, Michael Bommarito wrote:
>>>> On Tue, Aug 11, 2026 at 3:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>> Any progress with fixing this for v7.2?
>>>>
>>>> I would like to fix this since I started the problem with the original
>>>> patch, but I feel a bit stuck.  My v1 and v2 patches would not have
>>>> triggered the build failure, but Gao made valid points about the
>>>> trade-offs that led us to this v3.  Maybe it would be worth your
>>>> opinion on the config approach in those earlier patches?
>>>
>>> Sorry about the late reply.
>>>
>>> As I said, I really dislike hardcoded range, but it is an issue that no
>>> NR_CPUS definition on CONFIG_SMP:
>>>
>>> I wonder if the following diff resolves the m68k issue (I'm not an
>>> Kconfig expert but it seems to work on x86_64 !CONFIG_SMP):
>>>
>>> diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
>>> index 8ca1767dafb6..2dfc313588d2 100644
>>> --- a/fs/erofs/Kconfig
>>> +++ b/fs/erofs/Kconfig
>>> @@ -134,7 +134,8 @@ config EROFS_FS_ZIP_LZMA
>>>   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
>>> +       range 1 NR_CPUS if SMP
>>> +       range 1 1 if !SMP
>>>          default 16
>>>          help
>>>            By default EROFS allocates one LZMA decompression stream per CPU.
>>
>> Thank you, that seems to work (despite still seeing the warning on m68k,
>> as NR_CPUS does not exist).
>>
> 
> ...
> 
>>
>>        $ make ARCH=m68k allmodconfig
>>       fs/erofs/Kconfig:137:warning: range is invalid
>>
>>   Warning...
>>
> 
> Yes, other arches shouldn't have the warning because I think other
> arches (including microblaze) defines NR_CPUS in Kconfig, except m68k.
> 

That is not entirely true. openrisc only has it if SMP=y. But it still
does not generate the warning for some reason.

> The following diff can eliminate the m68k warning above, I think m68k
> folks could consider this way if you really don't want to define an
> explicit NR_CPUS.  Anyway, I think it should go with another patch:
> 
> ```
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 11835eb59d94..90499f126c73 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -44,6 +44,9 @@ config M68K
>   	select UACCESS_MEMCPY if !MMU
>   	select ZONE_DMA
>   
> +config NR_CPUS
> +	int

I would suggest to add

	default 1

Guenter

> +
>   config CPU_BIG_ENDIAN
>   	def_bool y
> ```
> 
> I will try to form a formal patch (with the diff in the previous reply)
> directly to Linus (since I don't have other urgent patches for
> Linux 7.2.)
> 
> Thanks,
> Gao Xiang