[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

[...]