From nobody Sun Feb 8 02:55:57 2026 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 597972D47E3 for ; Sat, 10 Jan 2026 11:47:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768045640; cv=none; b=DHRcj4EnrEg6d9iCreEs+32mIA+IhGVLdMuHWZWEIBX10V5qBtpnWEbcxAnjFox940Zc7OVuZo6mmiycg2nZdUreDUyXVNYtOaAwJGk6lr2ZOY+gV6cseEeR6PgaZJmYLiOiVkIMxb+Ou6vQbApDToq2WAH8Xr3g9hOawtqjl2o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768045640; c=relaxed/simple; bh=Kaj+y62UtwzsZdZl0F83EpgTqWskOUfMvf9zJIPEiso=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SG/uz9ukHDj7ZevYSDvS4BLeIq28/DOiT3CrYEHAnWHVnVWe3KD5K/hCs2RB5XzOwJDyJT5WSL0t1mJ1ETqoErrGeDRBxSlE80zsvCrbVtt9v74DX2hhfuVS8RHflB3gQKKGItrwdiWkz3oL3ed9hy7crb3y/g09oGtkWZFPfYU= 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=bi34xEOs; arc=none smtp.client-ip=115.124.30.124 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="bi34xEOs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1768045629; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=/xVX2xwp86WqwqboDTxGebQFvu/A9/i4zeyqWjKoYTI=; b=bi34xEOsXS0VLswQErA/K0qp3q+r2f+A2XEeE7DpqTAwlRmIlSwgX58kBmz2XOH3KtCdkeAFPfvbaAaZDfrztOSR9ajxNJuhIr/6UC/t5wZY1R2zspLMGwGmrEvF3tPv/TgawXipa3CsyJN0hqXPDEetOCrOVeUSjlSCbaRSZPk= Received: from x31i01179.sqa.na131.tbsite.net(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WwjsW9U_1768045624 cluster:ay36) by smtp.aliyun-inc.com; Sat, 10 Jan 2026 19:47:09 +0800 From: Gao Xiang To: Linus Torvalds , linux-erofs@lists.ozlabs.org Cc: LKML , Amir Goldstein , Alexander Larsson , Dusty Mabe , Chao Yu , Sheng Yong , Zhiguo Niu , Christian Brauner , Miklos Szeredi , Gao Xiang Subject: [PATCH] erofs: fix file-backed mounts no longer working on EROFS partitions Date: Sat, 10 Jan 2026 19:47:03 +0800 Message-ID: <20260110114703.3461706-1-hsiangkao@linux.alibaba.com> X-Mailer: git-send-email 2.43.5 In-Reply-To: References: 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" Sheng Yong reported [1] that Android APEX images didn't work with [PATCH v2] of upstream commit 072a7c7cdbea ("erofs: don't bother with s_stack_depth increasing for now") because "EROFS-formatted APEX file images can be stored within an EROFS-formatted Android system partition." In response, I sent a quick fat-fingered [PATCH v3] to address the report. Unfortunately, the updated condition was incorrect: 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 && !sb->s_bdev) ||=20 + inode->i_sb->s_stack_depth) { The condition `!sb->s_bdev` is always true for all file-backed EROFS mounts, making the check effectively a no-op. The real fix tested and confirmed by Sheng Yong [2] at that time was [PATCH v3 RESEND], which correctly ensures the following EROFS^2 setup works: EROFS (on a block device) + EROFS (file-backed mount) But sadly I screwed it up again by upstreaming the outdated [PATCH v3] and I should be blamed. This patch applies the same logic as the delta between the upstream [PATCH v3] and the real fix [PATCH v3 RESEND]. Reported-by: Sheng Yong Closes: https://lore.kernel.org/r/3acec686-4020-4609-aee4-5dae7b9b0093@gmai= l.com [1] Fixes: 072a7c7cdbea ("erofs: don't bother with s_stack_depth increasing for= now") Link: https://lore.kernel.org/r/243f57b8-246f-47e7-9fb1-27a771e8e9e8@gmail.= com [2] Signed-off-by: Gao Xiang --- Hi Linus, As suggested by Amir, I send out the patch to fix the broken fix. If possible, could you help apply this patch directly? If you perfer another pull request I will do later too after a sleep, but I guess I will just repeat my stupid mistake again in the pull request and the tag message. Thanks, Gao Xiang fs/erofs/super.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/erofs/super.c b/fs/erofs/super.c index e93264034b5d..5136cda5972a 100644 --- a/fs/erofs/super.c +++ b/fs/erofs/super.c @@ -655,7 +655,8 @@ static int erofs_fc_fill_super(struct super_block *sb, = struct fs_context *fc) */ if (erofs_is_fileio_mode(sbi)) { inode =3D file_inode(sbi->dif0.file); - if ((inode->i_sb->s_op =3D=3D &erofs_sops && !sb->s_bdev) || + if ((inode->i_sb->s_op =3D=3D &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; --=20 2.43.5