From nobody Sun Feb 8 09:12:59 2026 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06BBC2BDC1B for ; Wed, 31 Dec 2025 20:42:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.110 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767213761; cv=none; b=ehERi6fiKPMGGzaZLNCKNSTHCdoEl/dscxo7EwmO+oXb2CIKnG0jgtdWDN1bCXEq/S7xbH5GaK5+HehtJvss8ZjRMRLvBk2ZPIMHEuB0K5h+BJ5cptVwKj8R26Gr39FrIDWmkLOh1E4txcDycJqcuFmwpNevgig8/8wlbgAb/cs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767213761; c=relaxed/simple; bh=DfuNA9tgfb5REPDdGvQ/Vs531YHwnubqm6XtJ6yOhpc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Du4eaxrrmlb/Nk2JdYybXMIcdwg5WW7QuCOIz3IkGymN9nMDzwv92Hd3dAzWK0qC0mM4iClWLe8s/RnUI3UZLyrK58UeCHIvQjkQtCN5MkiYV6PrlapCVhTlKOCXwgDpJTDNw62LmZUbmxApHSYa8N9E3tfR04ylF0imVLVxaXY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=qWsWF9VV; arc=none smtp.client-ip=115.124.30.110 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="qWsWF9VV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1767213751; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=Bw8yz9UYkEEoUZSlDqyPzOJKY0KLWNDhlh8GnINWqQ4=; b=qWsWF9VVMHM6NTZYkS28Q497J2kkTkIVge83JhnOVFxZnIXCgKO34fvh+u02WrVP9Lv/rzOusuQ4mNXODW1eWxeMT9UZhOyax0hgX2nJY5dPjkK3Y4YSrnihtU4Mac/fx80MYrTX1YwjvZia086+zQDmZFd4DpDxFi5h9kknlmY= Received: from x31i01179.sqa.na131.tbsite.net(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0Ww21VLm_1767213745 cluster:ay36) by smtp.aliyun-inc.com; Thu, 01 Jan 2026 04:42:30 +0800 From: Gao Xiang To: linux-erofs@lists.ozlabs.org Cc: LKML , Gao Xiang , Amir Goldstein , Alexander Larsson , Christian Brauner , Miklos Szeredi Subject: [PATCH] erofs: don't bother with s_stack_depth increasing for now Date: Thu, 1 Jan 2026 04:42:25 +0800 Message-ID: <20251231204225.2752893-1-hsiangkao@linux.alibaba.com> X-Mailer: git-send-email 2.43.5 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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, but it breaks composefs mounts, which need erofs+ovl^2 sometimes (and such setups are already used in production for quite long time) since `s_stack_depth` can be 3 (i.e., FILESYSTEM_MAX_STACK_DEPTH needs to change from 2 to 3). After a long discussion on GitHub issues [1] about possible solutions, it seems there is no need to support nesting file-backed mounts as one conclusion (especially when increasing FILESYSTEM_MAX_STACK_DEPTH to 3). So let's disallow this right now, since there is always a way to use loopback devices as a fallback. Then, I started to wonder about an alternative EROFS quick fix to address the composefs mounts directly for this cycle: since EROFS is the only fs to support file-backed mounts and other stacked fses will just bump up `FILESYSTEM_MAX_STACK_DEPTH`, just check that `s_stack_depth` !=3D 0 and the backing inode is not from EROFS instead. At least it works for all known file-backed mount use cases (composefs, containerd, and Android APEX for some Android vendors), and the fix is self-contained. Let's defer increasing FILESYSTEM_MAX_STACK_DEPTH for now. Fixes: d53cd891f0e4 ("erofs: limit the level of fs stacking for file-backed= mounts") Closes: https://github.com/coreos/fedora-coreos-tracker/issues/2087 [1] Closes: https://lore.kernel.org/r/CAFHtUiYv4+=3D+JP_-JjARWjo6OwcvBj1wtYN=3D= z0QXwCpec9sXtg@mail.gmail.com Cc: Amir Goldstein Cc: Alexander Larsson Cc: Christian Brauner Cc: Miklos Szeredi Signed-off-by: Gao Xiang Acked-by: Alexander Larsson Acked-by: Amir Goldstein --- fs/erofs/super.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/fs/erofs/super.c b/fs/erofs/super.c index 937a215f626c..0cf41ed7ced8 100644 --- a/fs/erofs/super.c +++ b/fs/erofs/super.c @@ -644,14 +644,20 @@ 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 =3D - 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 =3D file_inode(sbi->dif0.file); + if (inode->i_sb->s_op =3D=3D &erofs_sops || + inode->i_sb->s_stack_depth) { + erofs_err(sb, "file-backed mounts cannot be applied to stacked fses"); return -ENOTBLK; } } --=20 2.43.5