fs/erofs/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
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.3Hi Gao,
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)
> ...
>
> 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>
Thanks for your patch, which is now commit a64d500b0078e16e ("erofs: fix
EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms") in v7.2.
> --- 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
I have just discovered another oddity: when you have less than 16
CPUS (including SMP=n), this default value is invalid, and "make
savedefconfig" will always write a line like
CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1
to the defconfig file, even if that is the default suggested value.
Needlessly polluting the defconfig files could be fixed using:
- default 16
+ default 16 if SMP && NR_CPUS >= 16
+ default NR_CPUS if SMP
+ default 1 if !SMP
Thoughts?
> 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
Hi Geert,
On Mon, Aug 17, 2026 at 09:32:51AM +0200, Geert Uytterhoeven wrote:
> Hi Gao,
>
..
>
> Thanks for your patch, which is now commit a64d500b0078e16e ("erofs: fix
> EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms") in v7.2.
>
> > --- 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
>
> I have just discovered another oddity: when you have less than 16
> CPUS (including SMP=n), this default value is invalid, and "make
> savedefconfig" will always write a line like
>
> CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1
>
> to the defconfig file, even if that is the default suggested value.
>
> Needlessly polluting the defconfig files could be fixed using:
>
> - default 16
> + default 16 if SMP && NR_CPUS >= 16
> + default NR_CPUS if SMP
I guess `default NR_CPUS if SMP && NR_CPUS < 16` would be better,
I'm not sure since I'm not handy in Kconfig stuffs.
> + default 1 if !SMP
>
> Thoughts?
In principle, that would be better, but may I ask if there is some
severe consequences out of one extra line of
CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1?
Since it has been fixed for many times, I hope if it could be improved
later if no severe impacts, sigh..
Thanks,
Gao Xiang
>
> > 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
>
Hi Gao,
On Mon, 17 Aug 2026 at 09:49, Gao Xiang <xiang@kernel.org> wrote:
> On Mon, Aug 17, 2026 at 09:32:51AM +0200, Geert Uytterhoeven wrote:
> > Thanks for your patch, which is now commit a64d500b0078e16e ("erofs: fix
> > EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms") in v7.2.
> >
> > > --- 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
> >
> > I have just discovered another oddity: when you have less than 16
> > CPUS (including SMP=n), this default value is invalid, and "make
> > savedefconfig" will always write a line like
> >
> > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1
> >
> > to the defconfig file, even if that is the default suggested value.
> >
> > Needlessly polluting the defconfig files could be fixed using:
> >
> > - default 16
> > + default 16 if SMP && NR_CPUS >= 16
> > + default NR_CPUS if SMP
>
> I guess `default NR_CPUS if SMP && NR_CPUS < 16` would be better,
> I'm not sure since I'm not handy in Kconfig stuffs.
Kconfig always picks the first matching default value, so you don't
have to exclude the "SMP && NR_CPUS >= 16" case here.
> > + default 1 if !SMP
If all architectures would always define NR_CPUS, one could replace
the last two lines by
default NR_CPUS
> >
> > Thoughts?
>
> In principle, that would be better, but may I ask if there is some
> severe consequences out of one extra line of
> CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1?
>
> Since it has been fixed for many times, I hope if it could be improved
> later if no severe impacts, sigh..
It causes more churn (defconfig updates), and makes the defconfig
files larger than needed.
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
On Mon, Aug 17, 2026 at 10:05:09AM +0200, Geert Uytterhoeven wrote:
> Hi Gao,
>
> On Mon, 17 Aug 2026 at 09:49, Gao Xiang <xiang@kernel.org> wrote:
> > On Mon, Aug 17, 2026 at 09:32:51AM +0200, Geert Uytterhoeven wrote:
> > > Thanks for your patch, which is now commit a64d500b0078e16e ("erofs: fix
> > > EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms") in v7.2.
> > >
> > > > --- 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
> > >
> > > I have just discovered another oddity: when you have less than 16
> > > CPUS (including SMP=n), this default value is invalid, and "make
> > > savedefconfig" will always write a line like
> > >
> > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1
> > >
> > > to the defconfig file, even if that is the default suggested value.
> > >
> > > Needlessly polluting the defconfig files could be fixed using:
> > >
> > > - default 16
> > > + default 16 if SMP && NR_CPUS >= 16
> > > + default NR_CPUS if SMP
> >
> > I guess `default NR_CPUS if SMP && NR_CPUS < 16` would be better,
> > I'm not sure since I'm not handy in Kconfig stuffs.
>
> Kconfig always picks the first matching default value, so you don't
> have to exclude the "SMP && NR_CPUS >= 16" case here.
>
> > > + default 1 if !SMP
>
> If all architectures would always define NR_CPUS, one could replace
> the last two lines by
>
> default NR_CPUS
>
> > >
> > > Thoughts?
> >
> > In principle, that would be better, but may I ask if there is some
> > severe consequences out of one extra line of
> > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1?
> >
> > Since it has been fixed for many times, I hope if it could be improved
> > later if no severe impacts, sigh..
>
> It causes more churn (defconfig updates), and makes the defconfig
> files larger than needed.
Could you submit a formal patch directly (since you found it and
suggested a version)?
so I could submit it along with the pull request if you're fine with it.
Thanks,
Gao Xiang
>
> 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
>
Hi Gao,
On Mon, 17 Aug 2026 at 10:10, Gao Xiang <xiang@kernel.org> wrote:
> On Mon, Aug 17, 2026 at 10:05:09AM +0200, Geert Uytterhoeven wrote:
> > On Mon, 17 Aug 2026 at 09:49, Gao Xiang <xiang@kernel.org> wrote:
> > > On Mon, Aug 17, 2026 at 09:32:51AM +0200, Geert Uytterhoeven wrote:
> > > > Thanks for your patch, which is now commit a64d500b0078e16e ("erofs: fix
> > > > EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms") in v7.2.
> > > >
> > > > > --- 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
> > > >
> > > > I have just discovered another oddity: when you have less than 16
> > > > CPUS (including SMP=n), this default value is invalid, and "make
> > > > savedefconfig" will always write a line like
> > > >
> > > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1
> > > >
> > > > to the defconfig file, even if that is the default suggested value.
> > > >
> > > > Needlessly polluting the defconfig files could be fixed using:
> > > >
> > > > - default 16
> > > > + default 16 if SMP && NR_CPUS >= 16
> > > > + default NR_CPUS if SMP
> > >
> > > I guess `default NR_CPUS if SMP && NR_CPUS < 16` would be better,
> > > I'm not sure since I'm not handy in Kconfig stuffs.
> >
> > Kconfig always picks the first matching default value, so you don't
> > have to exclude the "SMP && NR_CPUS >= 16" case here.
> >
> > > > + default 1 if !SMP
> >
> > If all architectures would always define NR_CPUS, one could replace
> > the last two lines by
> >
> > default NR_CPUS
> >
> > > >
> > > > Thoughts?
> > >
> > > In principle, that would be better, but may I ask if there is some
> > > severe consequences out of one extra line of
> > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1?
> > >
> > > Since it has been fixed for many times, I hope if it could be improved
> > > later if no severe impacts, sigh..
> >
> > It causes more churn (defconfig updates), and makes the defconfig
> > files larger than needed.
>
> Could you submit a formal patch directly (since you found it and
> suggested a version)?
>
> so I could submit it along with the pull request if you're fine with it.
Will do, I want to do a bit more testing first...
In addition, usability can be improved by hiding the prompt on UP
systems:
- int "EROFS LZMA default maximum decompression streams"
+ int "EROFS LZMA default maximum decompression streams" if SMP
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
Hi Geert,
On Mon, Aug 17, 2026 at 10:43:34AM +0200, Geert Uytterhoeven wrote:
> Hi Gao,
>
...
> > > >
> > > > In principle, that would be better, but may I ask if there is some
> > > > severe consequences out of one extra line of
> > > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1?
> > > >
> > > > Since it has been fixed for many times, I hope if it could be improved
> > > > later if no severe impacts, sigh..
> > >
> > > It causes more churn (defconfig updates), and makes the defconfig
> > > files larger than needed.
> >
> > Could you submit a formal patch directly (since you found it and
> > suggested a version)?
> >
> > so I could submit it along with the pull request if you're fine with it.
>
> Will do, I want to do a bit more testing first...
Ok, anyway, I will try to submit a PR hours later.
if there is a patch, the worst case is that it's included in
the follow-up pull request.
> In addition, usability can be improved by hiding the prompt on UP
> systems:
>
> - int "EROFS LZMA default maximum decompression streams"
> + int "EROFS LZMA default maximum decompression streams" if SMP
>
I hope CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is a user-visible
configuration (and the Kconfig text helps too) no matter the platform
is UP or not (but it can be omitted in .config) even there is the only
one choice in menuconfig for example on UP platforms.
Thanks,
Gao Xiang
> 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
>
Hi Gao,
On Mon, 17 Aug 2026 at 11:05, Gao Xiang <xiang@kernel.org> wrote:
> On Mon, Aug 17, 2026 at 10:43:34AM +0200, Geert Uytterhoeven wrote:
> > > > > In principle, that would be better, but may I ask if there is some
> > > > > severe consequences out of one extra line of
> > > > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1?
> > > > >
> > > > > Since it has been fixed for many times, I hope if it could be improved
> > > > > later if no severe impacts, sigh..
> > > >
> > > > It causes more churn (defconfig updates), and makes the defconfig
> > > > files larger than needed.
> > >
> > > Could you submit a formal patch directly (since you found it and
> > > suggested a version)?
> > >
> > > so I could submit it along with the pull request if you're fine with it.
> >
> > Will do, I want to do a bit more testing first...
>
> Ok, anyway, I will try to submit a PR hours later.
> if there is a patch, the worst case is that it's included in
> the follow-up pull request.
>
> > In addition, usability can be improved by hiding the prompt on UP
> > systems:
> >
> > - int "EROFS LZMA default maximum decompression streams"
> > + int "EROFS LZMA default maximum decompression streams" if SMP
> >
>
> I hope CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is a user-visible
> configuration (and the Kconfig text helps too) no matter the platform
> is UP or not (but it can be omitted in .config) even there is the only
> one choice in menuconfig for example on UP platforms.
Why do you prefer it to be a user-visible option on UP?
In general, we try not to bother the user with questions about
configuration options that do not matter for him, or that offer only
a single valid answer.
IMHO even "if SMP && EXPERT" would make sense...
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
On Mon, Aug 17, 2026 at 11:21:33AM +0200, Geert Uytterhoeven wrote:
> Hi Gao,
>
> On Mon, 17 Aug 2026 at 11:05, Gao Xiang <xiang@kernel.org> wrote:
> > On Mon, Aug 17, 2026 at 10:43:34AM +0200, Geert Uytterhoeven wrote:
> > > > > > In principle, that would be better, but may I ask if there is some
> > > > > > severe consequences out of one extra line of
> > > > > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1?
> > > > > >
> > > > > > Since it has been fixed for many times, I hope if it could be improved
> > > > > > later if no severe impacts, sigh..
> > > > >
> > > > > It causes more churn (defconfig updates), and makes the defconfig
> > > > > files larger than needed.
> > > >
> > > > Could you submit a formal patch directly (since you found it and
> > > > suggested a version)?
> > > >
> > > > so I could submit it along with the pull request if you're fine with it.
> > >
> > > Will do, I want to do a bit more testing first...
> >
> > Ok, anyway, I will try to submit a PR hours later.
> > if there is a patch, the worst case is that it's included in
> > the follow-up pull request.
> >
> > > In addition, usability can be improved by hiding the prompt on UP
> > > systems:
> > >
> > > - int "EROFS LZMA default maximum decompression streams"
> > > + int "EROFS LZMA default maximum decompression streams" if SMP
> > >
> >
> > I hope CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is a user-visible
> > configuration (and the Kconfig text helps too) no matter the platform
> > is UP or not (but it can be omitted in .config) even there is the only
> > one choice in menuconfig for example on UP platforms.
>
> Why do you prefer it to be a user-visible option on UP?
> In general, we try not to bother the user with questions about
> configuration options that do not matter for him, or that offer only
> a single valid answer.
>
> IMHO even "if SMP && EXPERT" would make sense...
I think users should not be bothered with !SMP in the beginning.
CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS impacts the default
LZMA maximum memory usage, I hope it shows the same for both SMP or
!SMP (even it cannot be configured on !SMP, since it clearly shows
to users the number and indicates how the default LZMA stream
derives in general.)
I think it's unlike something that is totally disabled in !SMP (or
does't have such functionality in SMP), I think that is more sense
to hide it in the configuration but here the DEFAULT_MAX_STREAM is still
meaningful and is 1.
Thanks,
Gao Xiang
>
> 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
>
Hi Gao,
On Mon, 17 Aug 2026 at 11:47, Gao Xiang <xiang@kernel.org> wrote:
> On Mon, Aug 17, 2026 at 11:21:33AM +0200, Geert Uytterhoeven wrote:
> > On Mon, 17 Aug 2026 at 11:05, Gao Xiang <xiang@kernel.org> wrote:
> > > On Mon, Aug 17, 2026 at 10:43:34AM +0200, Geert Uytterhoeven wrote:
> > > > > > > In principle, that would be better, but may I ask if there is some
> > > > > > > severe consequences out of one extra line of
> > > > > > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1?
> > > > > > >
> > > > > > > Since it has been fixed for many times, I hope if it could be improved
> > > > > > > later if no severe impacts, sigh..
> > > > > >
> > > > > > It causes more churn (defconfig updates), and makes the defconfig
> > > > > > files larger than needed.
> > > > >
> > > > > Could you submit a formal patch directly (since you found it and
> > > > > suggested a version)?
> > > > >
> > > > > so I could submit it along with the pull request if you're fine with it.
> > > >
> > > > Will do, I want to do a bit more testing first...
> > >
> > > Ok, anyway, I will try to submit a PR hours later.
> > > if there is a patch, the worst case is that it's included in
> > > the follow-up pull request.
> > >
> > > > In addition, usability can be improved by hiding the prompt on UP
> > > > systems:
> > > >
> > > > - int "EROFS LZMA default maximum decompression streams"
> > > > + int "EROFS LZMA default maximum decompression streams" if SMP
> > > >
> > >
> > > I hope CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is a user-visible
> > > configuration (and the Kconfig text helps too) no matter the platform
> > > is UP or not (but it can be omitted in .config) even there is the only
> > > one choice in menuconfig for example on UP platforms.
> >
> > Why do you prefer it to be a user-visible option on UP?
> > In general, we try not to bother the user with questions about
> > configuration options that do not matter for him, or that offer only
> > a single valid answer.
> >
> > IMHO even "if SMP && EXPERT" would make sense...
>
> I think users should not be bothered with !SMP in the beginning.
Because all systems are SMP? That is not true.
> CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS impacts the default
> LZMA maximum memory usage, I hope it shows the same for both SMP or
> !SMP (even it cannot be configured on !SMP, since it clearly shows
> to users the number and indicates how the default LZMA stream
> derives in general.)
I disagree: Kconfig is not meant to document underlying mechanisms
that are not relevant for the current configuration.
Anyway, I have now submitted "[PATCH] erofs: Fix
EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS default logic"
https://lore.kernel.org/c480ed6b8bf38822263e2c5b7cf32b28600f212d.1787219898.git.geert+renesas@glider.be/
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
On Mon, Aug 17, 2026 at 05:47:24PM +0800, Gao Xiang wrote:
> On Mon, Aug 17, 2026 at 11:21:33AM +0200, Geert Uytterhoeven wrote:
> > Hi Gao,
> >
> > On Mon, 17 Aug 2026 at 11:05, Gao Xiang <xiang@kernel.org> wrote:
> > > On Mon, Aug 17, 2026 at 10:43:34AM +0200, Geert Uytterhoeven wrote:
> > > > > > > In principle, that would be better, but may I ask if there is some
> > > > > > > severe consequences out of one extra line of
> > > > > > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1?
> > > > > > >
> > > > > > > Since it has been fixed for many times, I hope if it could be improved
> > > > > > > later if no severe impacts, sigh..
> > > > > >
> > > > > > It causes more churn (defconfig updates), and makes the defconfig
> > > > > > files larger than needed.
> > > > >
> > > > > Could you submit a formal patch directly (since you found it and
> > > > > suggested a version)?
> > > > >
> > > > > so I could submit it along with the pull request if you're fine with it.
> > > >
> > > > Will do, I want to do a bit more testing first...
> > >
> > > Ok, anyway, I will try to submit a PR hours later.
> > > if there is a patch, the worst case is that it's included in
> > > the follow-up pull request.
> > >
> > > > In addition, usability can be improved by hiding the prompt on UP
> > > > systems:
> > > >
> > > > - int "EROFS LZMA default maximum decompression streams"
> > > > + int "EROFS LZMA default maximum decompression streams" if SMP
> > > >
> > >
> > > I hope CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is a user-visible
> > > configuration (and the Kconfig text helps too) no matter the platform
> > > is UP or not (but it can be omitted in .config) even there is the only
> > > one choice in menuconfig for example on UP platforms.
> >
> > Why do you prefer it to be a user-visible option on UP?
> > In general, we try not to bother the user with questions about
> > configuration options that do not matter for him, or that offer only
> > a single valid answer.
> >
> > IMHO even "if SMP && EXPERT" would make sense...
>
> I think users should not be bothered with !SMP in the beginning.
>
> CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS impacts the default
> LZMA maximum memory usage, I hope it shows the same for both SMP or
> !SMP (even it cannot be configured on !SMP, since it clearly shows
> to users the number and indicates how the default LZMA stream
> derives in general.)
>
> I think it's unlike something that is totally disabled in !SMP (or
> does't have such functionality in SMP), I think that is more sense
^ !SMP
> to hide it in the configuration but here the DEFAULT_MAX_STREAM is still
> meaningful and is 1.
In other words, if NR_CPUS is defined unconditionally (regardless of
SMP or not like the current status), from the user perspective, I
think SMP inclusion here has no real gain, and it should be just
`range 1 NR_CPUS` simply as a unique per-fs configuration.
Thanks,
Gao Xiang
>
> Thanks,
> Gao Xiang
>
> >
> > 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
> >
>
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
[...]
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
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
>
© 2016 - 2026 Red Hat, Inc.