public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: linux-erofs@lists.ozlabs.org
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"Gao Xiang" <hsiangkao@linux.alibaba.com>,
	"Dusty Mabe" <dusty@dustymabe.com>,
	"Timothée Ravier" <tim@siosm.fr>,
	"Alekséi Naidénov" <an@digitaltide.io>,
	"Amir Goldstein" <amir73il@gmail.com>,
	"Alexander Larsson" <alexl@redhat.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Miklos Szeredi" <mszeredi@redhat.com>,
	"Sheng Yong" <shengyong1@xiaomi.com>,
	"Zhiguo Niu" <niuzhiguo84@gmail.com>
Subject: [PATCH v3 RESEND] erofs: don't bother with s_stack_depth increasing for now
Date: Thu,  8 Jan 2026 11:07:09 +0800	[thread overview]
Message-ID: <20260108030709.3305545-1-hsiangkao@linux.alibaba.com> (raw)
In-Reply-To: <3acec686-4020-4609-aee4-5dae7b9b0093@gmail.com>

Previously, commit d53cd891f0e4 ("erofs: limit the level of fs stacking
for file-backed mounts") bumped `s_stack_depth` by one to avoid kernel
stack overflow when stacking an unlimited number of EROFS on top of
each other.

This fix breaks composefs mounts, which need EROFS+ovl^2 sometimes
(and such setups are already used in production for quite a long time).

One way to fix this regression is to bump FILESYSTEM_MAX_STACK_DEPTH
from 2 to 3, but proving that this is safe in general is a high bar.

After a long discussion on GitHub issues [1] about possible solutions,
one conclusion is that there is no need to support nesting file-backed
EROFS mounts on stacked filesystems, because there is always the option
to use loopback devices as a fallback.

As a quick fix for the composefs regression for this cycle, instead of
bumping `s_stack_depth` for file backed EROFS mounts, we disallow
nesting file-backed EROFS over EROFS and over filesystems with
`s_stack_depth` > 0.

This works for all known file-backed mount use cases (composefs,
containerd, and Android APEX for some Android vendors), and the fix is
self-contained.

Essentially, we are allowing one extra unaccounted fs stacking level of
EROFS below stacking filesystems, but EROFS can only be used in the read
path (i.e. overlayfs lower layers), which typically has much lower stack
usage than the write path.

We can consider increasing FILESYSTEM_MAX_STACK_DEPTH later, after more
stack usage analysis or using alternative approaches, such as splitting
the `s_stack_depth` limitation according to different combinations of
stacking.

Fixes: d53cd891f0e4 ("erofs: limit the level of fs stacking for file-backed mounts")
Reported-and-tested-by: Dusty Mabe <dusty@dustymabe.com>
Reported-by: Timothée Ravier <tim@siosm.fr>
Closes: https://github.com/coreos/fedora-coreos-tracker/issues/2087 [1]
Reported-by: "Alekséi Naidénov" <an@digitaltide.io>
Closes: https://lore.kernel.org/r/CAFHtUiYv4+=+JP_-JjARWjo6OwcvBj1wtYN=z0QXwCpec9sXtg@mail.gmail.com
Acked-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Alexander Larsson <alexl@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Miklos Szeredi <mszeredi@redhat.com>
Cc: Sheng Yong <shengyong1@xiaomi.com>
Cc: Zhiguo Niu <niuzhiguo84@gmail.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
---
v2->v3 RESEND:
 - Exclude bdev-backed EROFS mounts since it will be a real terminal fs
   as pointed out by Sheng Yong (APEX will rely on this);

 - Preserve previous "Acked-by:" and "Tested-by:" since it's trivial.

 fs/erofs/super.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index 937a215f626c..5136cda5972a 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -644,14 +644,21 @@ static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *fc)
 		 * fs contexts (including its own) due to self-controlled RO
 		 * accesses/contexts and no side-effect changes that need to
 		 * context save & restore so it can reuse the current thread
-		 * context.  However, it still needs to bump `s_stack_depth` to
-		 * avoid kernel stack overflow from nested filesystems.
+		 * context.
+		 * However, we still need to prevent kernel stack overflow due
+		 * to filesystem nesting: just ensure that s_stack_depth is 0
+		 * to disallow mounting EROFS on stacked filesystems.
+		 * Note: s_stack_depth is not incremented here for now, since
+		 * EROFS is the only fs supporting file-backed mounts for now.
+		 * It MUST change if another fs plans to support them, which
+		 * may also require adjusting FILESYSTEM_MAX_STACK_DEPTH.
 		 */
 		if (erofs_is_fileio_mode(sbi)) {
-			sb->s_stack_depth =
-				file_inode(sbi->dif0.file)->i_sb->s_stack_depth + 1;
-			if (sb->s_stack_depth > FILESYSTEM_MAX_STACK_DEPTH) {
-				erofs_err(sb, "maximum fs stacking depth exceeded");
+			inode = file_inode(sbi->dif0.file);
+			if ((inode->i_sb->s_op == &erofs_sops &&
+			     !inode->i_sb->s_bdev) ||
+			    inode->i_sb->s_stack_depth) {
+				erofs_err(sb, "file-backed mounts cannot be applied to stacked fses");
 				return -ENOTBLK;
 			}
 		}
-- 
2.43.5


  parent reply	other threads:[~2026-01-08  3:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20251231204225.2752893-1-hsiangkao@linux.alibaba.com>
     [not found] ` <CAOQ4uxjjxUHr3Tkxo9PkrBUPcYG1C309cYA9EEvk1-oVGcV_Og@mail.gmail.com>
     [not found]   ` <18246672-2c4f-415e-8667-2f826eb4fe19@linux.alibaba.com>
2026-01-04 10:01     ` [PATCH] erofs: don't bother with s_stack_depth increasing for now Amir Goldstein
2026-01-04 10:42       ` Gao Xiang
2026-01-04 18:44         ` Amir Goldstein
2026-01-04 21:14           ` Gao Xiang
2026-01-06 17:05             ` [PATCH v2] " Gao Xiang
2026-01-07 14:11               ` Dusty Mabe
2026-01-08  2:26               ` Sheng Yong
2026-01-08  2:32                 ` Gao Xiang
2026-01-08  3:10                   ` Gao Xiang
2026-01-08  8:02                     ` Amir Goldstein
2026-01-08  8:05                       ` Gao Xiang
2026-01-08  8:24                         ` Amir Goldstein
2026-01-08  8:34                           ` Gao Xiang
2026-01-08 10:26                         ` David Laight
2026-01-08 12:30                           ` Gao Xiang
2026-01-08  2:38                 ` [PATCH v3] " Gao Xiang
2026-01-08  3:07                 ` Gao Xiang [this message]
2026-01-08  9:14                   ` [PATCH v3 RESEND] " Sheng Yong
2026-01-08  9:25                     ` Gao Xiang
2026-01-08  9:30                       ` Sheng Yong
2026-01-08  9:28                   ` Zhiguo Niu
2026-01-08  9:31                     ` Gao Xiang
2026-01-10  1:45                   ` Chao Yu
2026-01-12 12:46                   ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260108030709.3305545-1-hsiangkao@linux.alibaba.com \
    --to=hsiangkao@linux.alibaba.com \
    --cc=alexl@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=an@digitaltide.io \
    --cc=brauner@kernel.org \
    --cc=dusty@dustymabe.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=niuzhiguo84@gmail.com \
    --cc=shengyong1@xiaomi.com \
    --cc=tim@siosm.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox