From mboxrd@z Thu Jan 1 00:00:00 1970 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 50ADA18BC3B for ; Sun, 4 Jan 2026 03:56:49 +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=1767499013; cv=none; b=VBbhfefGYnvNplLGMkIH6Fa3bQ7XH5kMnPcdyIjWq+Fqy6+R+FXUGNJz+NtkRDXIZqof7E35Gs/miDxm3L1+fPzTpJx9HBQKefL0lNmhruQDhbXQEewGg2d/oHIzwEctzy0kjKprUixgmXfGrJoGAGs70kdtqTw5qQIkLc5HpeY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767499013; c=relaxed/simple; bh=hmlZu60H4R1986D1yzjTjMgXiY3k9OEhor4AEZYjv+s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qmKYTPm0NZ2V7pxwoyyeuw1fEeNvTWMLJ/yNZP33eOSjKLfyzlUmkGkfJ2UdGKM4zw04uQjh88xIrS9ZGYEXKtQqaVGoQZxhafE8ex4jz2DHnilW5RMS2RR95oT5/UqUBocG3GYRio45CQwEKO3ajfH5cc6AVgobtWoTJ5hHlrE= 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=axL8QPcf; 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="axL8QPcf" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1767499002; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=I1UBQbTJKdg44fsUKvwMvyyyIxcE0vPeGXNIza6CZMs=; b=axL8QPcf5inav+V6QpwrkE2fasMK3KRXk3JQfteJVIzk9UBAb0HECZnkdN/uRDGOsIFJ6X4ZT7+ml3XMMw+/V2j+gv2NZ2m2GyqmB/zyCmhX4bHoJOAmvTqvXu3WC2yLWYPyALMxxV9FFMwa2iH1cmJQgFsnUEHZtmv0ttOCfnA= Received: from 30.221.131.151(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WwB0uN9_1767498999 cluster:ay36) by smtp.aliyun-inc.com; Sun, 04 Jan 2026 11:56:40 +0800 Message-ID: <18246672-2c4f-415e-8667-2f826eb4fe19@linux.alibaba.com> Date: Sun, 4 Jan 2026 11:56:39 +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] erofs: don't bother with s_stack_depth increasing for now To: Amir Goldstein Cc: linux-erofs@lists.ozlabs.org, LKML , Alexander Larsson , Christian Brauner , Miklos Szeredi References: <20251231204225.2752893-1-hsiangkao@linux.alibaba.com> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Amir, On 2026/1/1 23:52, Amir Goldstein wrote: > On Wed, Dec 31, 2025 at 9:42 PM 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, 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` >> != 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+=+JP_-JjARWjo6OwcvBj1wtYN=z0QXwCpec9sXtg@mail.gmail.com >> Cc: Amir Goldstein >> Cc: Alexander Larsson >> Cc: Christian Brauner >> Cc: Miklos Szeredi >> Signed-off-by: Gao Xiang >> --- > > Acked-by: Amir Goldstein > > But you forgot to include details of the stack usage analysis you ran > with erofs+ovl^2 setup. > > I am guessing people will want to see this information before relaxing > s_stack_depth in this case. Sorry I didn't check emails these days, I'm not sure if posting detailed stack traces are useful, how about adding the following words: Note: There are some observations while evaluating the erofs + ovl^2 setup with an XFS backing fs: - Regular RW workloads traverse only one overlayfs layer regardless of the value of FILESYSTEM_MAX_STACK_DEPTH, because `upperdir=` cannot point to another overlayfs. Therefore, for pure RW workloads, the typical stack is always just: overlayfs + upper fs + underlay storage - For read-only workloads and the copy-up read part (ovl_splice_read), the difference can lie in how many overlays are nested. The stack just looks like either: ovl + ovl [+ erofs] + backing fs + underlay storage or ovl [+ erofs] + ext4/xfs + underlay storage - The fs reclaim path should be entered only once, so the writeback path will not re-enter. Sorry about my English, and I'm not sure if it's enough (e.g. FUSE passthrough part). I will look for your further inputs (and other acks) before sending this patch upstream. (Also btw, i'm not sure if it's possible to optimize read_iter and splice_read stack usage even further in overlayfs, e.g. just recursive handling real file/path directly in the top overlayfs since the permission check is already done when opening the file.) Thanks, Gao Xiang > > Thanks, > Amir.