From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) (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 89FA2299937 for ; Thu, 8 Jan 2026 02:26:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767839204; cv=none; b=PviC/uhVDVuAmSon+5N2nkmJYylAdsSMidUQTufrGrwD2mVWneILs2XRXIj1Klr3c2/2ydl3GKVEGLbBWi7bOQpY4tz8vgesBChQ8wTNoRUoSzRFrCBlM69Fvdt075bZat2LQUWnvapiP6+wPges8PaDOoDbnksCRRexHEn+JJk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767839204; c=relaxed/simple; bh=JUqVjRUk9Ght0IhfZYovVkug4AGW3LuZwIJbtBD5sQw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PSjjd9unyrlYRGljhJADHsJPIFjLRX1kFDr0SntbyRq9xmudRuk6ZuUyzmzOPSZZCDGAH2axUVWG+MO9mAbR7ULtpAE5lye4tnlJ8R/PY1Fm1IJNVs/yrimWO/Dy2+w1TasPT13LNA7QbCbm8vKzUQGxpLzOXRhGEEgYAkNaV7g= 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=VsZpsr5X; arc=none smtp.client-ip=209.85.215.176 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="VsZpsr5X" Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-c026e074373so1498512a12.1 for ; Wed, 07 Jan 2026 18:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767839202; x=1768444002; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SlkG/EJNtxTQbmqNLHdB90183ZHhg2gpdFgNQmGYHqw=; b=VsZpsr5XIUG+DZtF1JXGDxMBhsFbJTYA5osbFHNKrBtEDkGd5EtXddaiQRwIkD7s9K hytVSx+SjopXJAUd1tgpWe+c19Lrpp7M1u/7nXtnkmr4HWLk6Iyy5z5h1f+my1mWfTah uezp7zi6drRJH1msrAfZ67JV2oXNTq0FLwqryVK4lsb0FUEQv9wv4GQrxlYqHEjfa4U5 vG3XUqdF68i92z6Q+WVTGeATLFSN9gnjfuJBVhLABU5yktVIGOY/0IIAhPa9zN87cNJd +rO+py3Nn6sTUngDynbS6myEdbU6K7fx6MSSBjNvV1TAJlOdE/s9c/3h1kXvojbx605o ucqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767839202; x=1768444002; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SlkG/EJNtxTQbmqNLHdB90183ZHhg2gpdFgNQmGYHqw=; b=YYC6Ma/9CGc9vZYbdp+WBnJSN71UOn7caK/Sl0F1eU1kgsdCAIchPg8CyavccSGvGY 0qgi4hSlN5Jw5wuUaXlMuRzbH8OQhMgkYlYLnVQSpE9Cd5I6o+aPmxaW29loPioGFGch +tWrqsdFdMtGDJOheFAQxQg3FHbfCBzgAsPZHi8Er0u5LWTcGEDd+zkQ/F0Po4a28WRW MV1de0FH3iEWRSq//irqRougIevCeK/CHt0xLNhG3qh1HZiemiv8mmikz0npiDCYJqZA kfWXPN6gIazEb197zX66VBmv/t6Bl6n6C4MPzGpBQTAJT7xtBE+xTYOpkyuZ/iwO+o/u L6Gg== X-Gm-Message-State: AOJu0YzJf/u0Sit+csDi9AGfQmWwQtvb/AQ9lZEQEFGheGY4ZRDD11gJ F8zVTybBuGBKh2sDzKNlfXC8xjuy6bf64lkx9a2vYPbRhdsSLUehZWtC X-Gm-Gg: AY/fxX4Qj80PR1dDKXtyhEWfiC7PBlTN9hNOITLbGslOsyBcQy+5l3AyGBaEwevYO0f qIJ3CQs60Dcri4YeA1eqgwpmqIIwMX4kJ5Dsto1ElBdc9IT1qr8T/7td6gReUiIWEyHgFJk2zlL 2GapwozUMeX/lhW8iZpBEM+EVSbxuXaQfjbDNqVxdxMdFepsf8z6QgSpUYVRh6s5+BpVHvtxaR7 jf4QO3KiKEBM3Hiu7Tnh8dyacLefsRFl70DXnYvVkjGO3M6yVkOF4pCIoKTfQ/fbHC9yAxHfxGy cH9UywWR8Sbv6r53WhLH6T5mEDy9DFtAU9DDgQnzB8QfD8ZFxyHU4N7C/MLOIYHD5w6daX3L87F QP9RpaqXXiMCrr2E0X39SYnIvC1e34CLBZFAYNi5OIP8RkB0v05Mu2K7khwLZ6jm4sIs84V+uFj FtTAXP+L+JIFHvnqCcFHexAw== X-Google-Smtp-Source: AGHT+IEGa+ws2SHQIi5xy8NLYinApzL2ZD35WLB81CyXBtazqNT3JFCWjfqFBKIDmDkCcdskllaiiA== X-Received: by 2002:a17:903:2292:b0:2a1:2ed4:ca1e with SMTP id d9443c01a7336-2a3ee4b72e8mr39060825ad.34.1767839201831; Wed, 07 Jan 2026 18:26:41 -0800 (PST) Received: from [10.189.144.225] ([43.224.245.249]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a3e3c3a303sm61626365ad.5.2026.01.07.18.26.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 18:26:41 -0800 (PST) Message-ID: <3acec686-4020-4609-aee4-5dae7b9b0093@gmail.com> Date: Thu, 8 Jan 2026 10:26:37 +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 Subject: Re: [PATCH v2] erofs: don't bother with s_stack_depth increasing for now To: Gao Xiang , linux-erofs@lists.ozlabs.org Cc: 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 , shengyong2021@gmail.com, shengyong1@xiaomi.com References: <0c34f3fa-c573-4343-b8ea-6832530f0069@linux.alibaba.com> <20260106170504.674070-1-hsiangkao@linux.alibaba.com> Content-Language: en-US, fr-CH From: Sheng Yong In-Reply-To: <20260106170504.674070-1-hsiangkao@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/7/26 01:05, 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-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 > Cc: Alexander Larsson > Cc: Christian Brauner > Cc: Miklos Szeredi > Cc: Sheng Yong > Cc: Zhiguo Niu > Signed-off-by: Gao Xiang > --- > v2: > - Update commit message (suggested by Amir in 1-on-1 talk); > - Add proper `Reported-by:`. > > 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 = > - 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 || Hi, Xiang In Android APEX scenario, apex images formatted as EROFS are packed in system.img which is also EROFS format. As a result, it will always fail to do APEX-file-backed mount since `inode->i_sb->s_op == &erofs_sops' is true. Any thoughts to handle such scenario? thanks, shengyong > + inode->i_sb->s_stack_depth) { > + erofs_err(sb, "file-backed mounts cannot be applied to stacked fses"); > return -ENOTBLK; > } > }