From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E9DB41E5CD for ; Thu, 8 Jan 2026 09:14:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767863693; cv=none; b=cGKQm5hYvnYyx2xMnrYAS+tVUvlD/JwbFbNGzrECMTlC8u88meqeKbaSDCdcLC8i3NGwI5R8hoM9ULyqEcjlV78oc4hFsMb51IA3GjKEz+q6o88Koex/iWvXGdwputqmwoNdJhUky4a9BerHYbsMUefU6Qzcr2lOf6BYHLDct34= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767863693; c=relaxed/simple; bh=O1kPS5MelCJnE3091PcMFc4fx3i6U389jcgBTmCDIts=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=nv+HzUEASBr+qZC68LK/sSUV6858rt082dcHmyw0r1vHyoMT0klNgze5vtJyqx92tVd6bn5y2q3Dxp+qREnqQD2W9NuIO31zoKwkHiTXh2XQqlYYVqWODzFZxW0Khhqt9YIkh1xqFK+9F7/SJbxvVY7Xpn3a7nX6k3mayCeJAQU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LpGRj7i6; arc=none smtp.client-ip=209.85.215.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LpGRj7i6" Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-b553412a19bso1562056a12.1 for ; Thu, 08 Jan 2026 01:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767863685; x=1768468485; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=P9A9CnNPkpLsRMHLIS50U2O5+Dp80nlM7WRY0+NXniA=; b=LpGRj7i6o3j1shQ0GljbsEC5sp2QecOg9X0CfhpDjUaKBruoGDeDtJ06Kb4Y0x1WTT gVpEVjQ4At+ObkzYOMJncdOB5DVOjeNfeNwyoCFkG6yVOXSWM2Yz0yYD1pwezHR9dNlC PbVa+qhTiF5qg5Eo0Ut8/fpBHNnjZzxHJJIr6FC1ySAy5A51cEsJykJB8S4I+SGCkrzC fm9TC3VslLEyM5iw713HP0AJMdN1fgSoDRRx5VieHy+M6+OUKXO4hFsLdV4KvMDfP5eL q7p0r6fXea3VGsZ3R3PD0S4xsDywva07mv4PPKbqS81uMj5ikGPWVMwzPgBCTgv8hA/r GJlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767863685; x=1768468485; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P9A9CnNPkpLsRMHLIS50U2O5+Dp80nlM7WRY0+NXniA=; b=jNNSfleXYqsQ7VC71QMEB7L880+IUf2gC1Fal8SecGaw7o6M2vKYBvQvUT6XdghsTH w59rrHJ5dDJYdPiZcwDz2pdj1dqI/4lzpDR94gdj/7cH499f/nS2IPNEbJEbEjNL5z/u BIuxq+KdZ8B2J52E0pb7RRuHhy+C5g+hCXdJFtRYrdAHysIHIx8oleSz4WMaE477Q5UJ fSIXWSvEhzuOgPVUnnbQhS4QQ/5FVPFSoE0/8QmUetRNcKd/QE+AbIW8nz+ccF8FSt7B Yip3t5k3XKdOcJdwcwY8+mrsLIa3r51KJZ/Y300mdDbvOchLWyIrrFsuDVrsQqccB17X hjSw== X-Forwarded-Encrypted: i=1; AJvYcCWG4BCcZZOrq4+sMqGsIn1XfHg0cVQS/ETVll72rbaTetDW8m3ZwW9C6kEUKVpSlJicPc499o83Q4N7+O4=@vger.kernel.org X-Gm-Message-State: AOJu0YxVFyNtrrCqP4xqGvlQk3lJauSq11YvhfjM8wtWkCUaTJWDBAL6 R3jPys9Ln2a4DaYgkSpZYiekQo5mxoad3RPesZb3n1KNkOj5Qlb+BQtn X-Gm-Gg: AY/fxX6Jo+hhh9OjjZw7RwRFjMevqXGmExpTMmEvrQJK41TdfXl/V4YZKNNmxZDDpES TKq+YnzcRQ15NgUAO/koCaOTmpdUz5LVzSiBVtgkreiAJGRC8oPiIHkwgUsdBHXmir6BMRD8ETN M+gmmXKEGIRhCFXdLWAS6m4KYXvqFQYF7VecpoweyufBBI3YfM1SB6YMBZNyBOszcTgGE5CAguW 1+EjxPN4ZsYZ7efQN9pCLbIHHlbCdg9i/YJoOeA+hLDHps3Vmw0aruhcswXOBiGnKiS+ux2x2ty Aq8q5oajB9GumpdDLfvd186eWQJ47czhp9d0ehcWJrbBO/WBpyp+1hXGANCgUE4RCtGD6MpkcId u1V0I4gOZJFiemrfJBRQMiBkUuH/n2DQoKtlXvusT+aOIdTZx4Kj25sHVHSxNYWCkBBrqV+c+vm NqM12N81rbWrz0d0/cGACE4g== X-Google-Smtp-Source: AGHT+IFN4bvajl/HnvO1CZQ3YQgySLPOlPc+6VtyxPcphHI+k8Jmt+inxmA3yYfVTtpOjwdyDkkOiA== X-Received: by 2002:a17:90b:3852:b0:343:b610:901c with SMTP id 98e67ed59e1d1-34f68cb9036mr5855290a91.26.1767863685375; Thu, 08 Jan 2026 01:14:45 -0800 (PST) Received: from [10.189.144.225] ([43.224.245.249]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-34f6af53004sm1950343a91.1.2026.01.08.01.14.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 01:14:45 -0800 (PST) Message-ID: <243f57b8-246f-47e7-9fb1-27a771e8e9e8@gmail.com> Date: Thu, 8 Jan 2026 17:14:40 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: shengyong2021@gmail.com, shengyong1@xiaomi.com, LKML , linux-fsdevel , Dusty Mabe , =?UTF-8?Q?Timoth=C3=A9e_Ravier?= , =?UTF-8?B?QWxla3PDqWkgTmFpZMOpbm92?= , Amir Goldstein , Alexander Larsson , Christian Brauner , Miklos Szeredi , Zhiguo Niu Subject: Re: [PATCH v3 RESEND] erofs: don't bother with s_stack_depth increasing for now To: Gao Xiang , linux-erofs@lists.ozlabs.org References: <3acec686-4020-4609-aee4-5dae7b9b0093@gmail.com> <20260108030709.3305545-1-hsiangkao@linux.alibaba.com> Content-Language: en-US, fr-CH From: Sheng Yong In-Reply-To: <20260108030709.3305545-1-hsiangkao@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/8/26 11:07, Gao Xiang wrote: > 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 > Reported-by: Timothée Ravier > Closes: https://github.com/coreos/fedora-coreos-tracker/issues/2087 [1] > Reported-by: "Alekséi Naidénov" > Closes: https://lore.kernel.org/r/CAFHtUiYv4+=+JP_-JjARWjo6OwcvBj1wtYN=z0QXwCpec9sXtg@mail.gmail.com > Acked-by: Amir Goldstein > Acked-by: Alexander Larsson > Cc: Christian Brauner > Cc: Miklos Szeredi > Cc: Sheng Yong > Cc: Zhiguo Niu > Signed-off-by: Gao Xiang Reviewed-and-tested-by: Sheng Yong I tested the APEX scenario on an Android phone. APEX images are filebacked-mounted correctly. And for a stacked APEX testcase, it reports error as expected. thanks, shengyong > --- > 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; > } > }