linux-toradex.git/fs/erofs/Kconfig, branch master

erofs: Fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS default logic

2026-08-24T04:20:11+00:00

When NR_CPUS is less than 16, or when SMP is disabled, the default value
of 16 is invalid.

While actual configuration picks up a sensible and valid default
(NR_CPUS or 1), "make savedefconfig" will still write a line like

    CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1

to the defconfig file, even if that matches the sensible default.

Avoid needlessly enlarging the defconfig files, and reduce churn for
updating them, by specifying valid defaults depending on SMP and
NR_CPUS.

While at it, make the prompt depend on SMP, as there is no point in
asking the user about the maximum number of decompression streams if
there is only one valid answer.

Fixes: c9b47e6b23114e93 ("erofs: cap LZMA stream pool size")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Guenter Roeck 
Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang

erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms

2026-08-14T14:44:41+00:00

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 that got fixed in commit 1fd495ef09ee
("m68k: Define NR_CPUS to 1")

Reported-by: SJ Park 
Link: https://lore.kernel.org/all/anuyFHLUGDjZWY4K@XiangdeMacBook-Pro.local/T/#u [1]
Closes: https://lore.kernel.org/r/20260728065447.91511-1-sj@kernel.org
Reported-by: Guenter Roeck 
Closes: https://lore.kernel.org/r/87853c96-cc8f-49e6-81b1-02bfe409e372@roeck-us.net
Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size")
Signed-off-by: Gao Xiang 
Tested-by: SJ Park 
Tested-by: Geert Uytterhoeven 
Signed-off-by: Linus Torvalds

erofs: cap LZMA stream pool size

2026-07-27T04:31:11+00:00

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 
Reviewed-by: Gao Xiang 
Signed-off-by: Gao Xiang

erofs: ensure valid f_path for page cache sharing

2026-07-27T04:31:02+00:00

Previously, backing files for page cache sharing were set up with
f_path left as NULL (only f_inode was valid).  It worked, but a recent
mincore fix relies on f_path.mnt and crashes (found by "erofs/028" on
7.2-rc4):

 BUG: kernel NULL pointer dereference, address: 0000000000000018
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP PTI
 CPU: 3 UID: 0 PID: 675528 Comm: fincore Not tainted 7.2.0-rc4-00002-g[]-dirty #1 PREEMPT(lazy)
 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014
 RIP: 0010:__do_sys_mincore+0xc0/0x2c0
 ...

Specify valid paths using valid disconnected dentries together with
erofs_ishare_mnt instead of leaving f_path empty, so they are more
like real backing files in a pseudo filesystem and standard
backing_file_open() can be used directly.

Fixes: e187bc02f8fa ("mm: do file ownership checks with the proper mount idmap")
Acked-by: Hongbo Li 
Signed-off-by: Gao Xiang

erofs: remove fscache backend entirely

2026-06-22T03:00:06+00:00

EROFS over fscache was introduced to provide image lazy pulling
functionality. After the feature landed, the fscache subsystem made
netfs a new hard dependency, which is unexpected for a local filesystem
and has an kernel-defined caching hierarchy which could be inflexible
compared to the fanotify pre-content hooks. Therefore, this feature has
been deprecated for almost two years.

As EROFS file-backed mounts and fanotify pre-content hooks both upstream
for a while and already providing equivalent functionality (erofs-utils
has supported fanotify pre-content hooks), let's remove the fscache
backend now.

The main application of this feature is Nydus [1], and they plan to move
to use fanotify pre-content hooks in the near future too.

I hope this patch can be merged into Linux 7.2, which is also motivated
by newly found implementation issues [2][3] that are not worth
investigating given the deprecation and limited development resources.
The associated fscache/cachefiles cleanup patch will follow separately
through the vfs tree (netfs) later: it seems fine since the codebase is
isolated by CONFIG_CACHEFILES_ONDEMAND.

[1] https://github.com/dragonflyoss/nydus/blob/v2.1.0/docs/nydus-fscache.md
[2] https://github.com/dragonflyoss/nydus/pull/1824
[3] https://lore.kernel.org/r/20260619135800.1594811-1-michael.bommarito@gmail.com

Acked-by: Jingbo Xu 
Signed-off-by: Gao Xiang

erofs: update the Kconfig description

2026-03-24T16:04:41+00:00

Refine the description to better highlight its features and use cases.

In addition, add instructions for building it as a module and clarify
the compression option.

Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang

erofs: update compression algorithm status

2026-02-05T09:45:20+00:00

The following changes are proposed in the upcoming Linux 7.0:

 - Enable LZMA support by default, as it's already in use by Fedora 42/43
   and some Android vendors for minimal filesystem sizes;

 - Promote DEFLATE and Zstandard out of EXPERIMENTAL status, given that
   they have been landed and well-tested for over a year and are
   already ready for general use.

Signed-off-by: Gao Xiang

erofs: support user-defined fingerprint name

2026-01-23T12:01:13+00:00

When creating the EROFS image, users can specify the fingerprint name.
This is to prepare for the upcoming inode page cache share.

Signed-off-by: Hongzhen Luo 
Signed-off-by: Hongbo Li 
Reviewed-by: Gao Xiang 
Signed-off-by: Gao Xiang

erofs: Do not select tristate symbols from bool symbols

2025-08-10T22:02:20+00:00

The EROFS filesystem has many configurable options, controlled through
boolean Kconfig symbols.  When enabled, these options may need to enable
additional library functionality elsewhere.  Currently this is done by
selecting the symbol for the additional functionality.  However, if
EROFS_FS itself is modular, and the target symbol is a tristate symbol,
the additional functionality is always forced built-in.

Selecting tristate symbols from a tristate symbol does keep modular
transitivity.  Hence fix this by moving selects of tristate symbols to
the main EROFS_FS symbol.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Gao Xiang 
Link: https://lore.kernel.org/r/da1b899e511145dd43fd2d398f64b2e03c6a39e7.1753879351.git.geert+renesas@glider.be
Signed-off-by: Gao Xiang

erofs: fix build error with CONFIG_EROFS_FS_ZIP_ACCEL=y

2025-07-24T11:43:04+00:00

fix build err:
 ld.lld: error: undefined symbol: crypto_req_done
   referenced by decompressor_crypto.c
       fs/erofs/decompressor_crypto.o:(z_erofs_crypto_decompress) in archive vmlinux.a
   referenced by decompressor_crypto.c
       fs/erofs/decompressor_crypto.o:(z_erofs_crypto_decompress) in archive vmlinux.a

 ld.lld: error: undefined symbol: crypto_acomp_decompress
   referenced by decompressor_crypto.c
       fs/erofs/decompressor_crypto.o:(z_erofs_crypto_decompress) in archive vmlinux.a

 ld.lld: error: undefined symbol: crypto_alloc_acomp
   referenced by decompressor_crypto.c
       fs/erofs/decompressor_crypto.o:(z_erofs_crypto_enable_engine) in archive vmlinux.a

Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202507161032.QholMPtn-lkp@intel.com/
Fixes: b4a29efc5146 ("erofs: support DEFLATE decompression by using Intel QAT")
Signed-off-by: Bo Liu (OpenAnolis) 
Link: https://lore.kernel.org/r/20250718033039.3609-1-liubo03@inspur.com
Reviewed-by: Gao Xiang 
Signed-off-by: Gao Xiang