From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 B2CDC19F40B; Sat, 10 Jan 2026 01:45:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768009545; cv=none; b=l+SScOaxMb4GXlsqErdZFuBNaOsZ8KqWt92wPolNaD2lHIsM1Qh5PCDRD3RD0Xvu+RnUR9zSDkqr4r0Q0q+w7MLVRWbq4pB5t2Vfh4kvT5eoDGPXE40IRHyh2FZ1M9Z8duaPXWo9mHTV373wc+N1EIBuhf5Je0ksAV7nodYdZCE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768009545; c=relaxed/simple; bh=nueUKQeE8eABviDIYLH468NZYrZZr1YRYAGw27ULbJ0=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=cbUPsdhB7t7i6zqE68/3LIMjA3xBGQThaSawLIE4To1lBSz1Kw67Uk9NaStGBq3sIKF1RlmIRnsgO2TF90wyy4L84oKHkmSRz99er0+chyM9ere7ug4a5at54FCeFIJ6lmBo6Q1WEsAmXsUziKtYog/zs08b83SLjGLzAHp8hKk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i1hwaVl4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="i1hwaVl4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 041DBC4CEF1; Sat, 10 Jan 2026 01:45:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768009545; bh=nueUKQeE8eABviDIYLH468NZYrZZr1YRYAGw27ULbJ0=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=i1hwaVl4RJlM92xX9Gl1Q/jvG9XgiWwW7RVb7fbPOhlUGj8SN80KzLjFvAIcGWcyj X6o4J03LzA+ZElKxt7+E173ywxHVhc1GAL3Uyb74Qy/IVMSd0qJm4dlfr4VVFyNtyw C/TRbSzmtJS4qk8yjU43lgVsDR/CgixjSphafixIx0JQEvQ+3b6Zedj6IOdTYk4pNe SoRC2x6jmVS2ZOaY5sMxgBng56rYZf0USTqg+9BE9cDtkLfbdwC5q28B4foRm8z26m JOUg8J22zimKg1a3s5WOkS4zqCLFzvQpytPrbiCkuF8cDsmDZfTFAn/HiqG80bYDyO ZFXjJ61UlitEA== Message-ID: <8d82106d-cb20-4034-aab2-3696dd5486c7@kernel.org> Date: Sat, 10 Jan 2026 09:45:56 +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: chao@kernel.org, LKML , linux-fsdevel , Dusty Mabe , =?UTF-8?Q?Timoth=C3=A9e_Ravier?= , =?UTF-8?B?QWxla3PDqWkgTmFpZMOpbm92?= , Amir Goldstein , Alexander Larsson , Christian Brauner , Miklos Szeredi , Sheng Yong , 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 From: Chao Yu 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/2026 11:07 AM, 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-by: Chao Yu Thanks,