From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (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 855B544EE2A for ; Thu, 8 Jan 2026 09:30:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767864620; cv=none; b=pPdZaKZ75QMSXnrN8zjzQMlCagfVSOcmO9gFen6amhn9L6maT1ZXsB4IArruh8CPCqAOLYIidg/3Ddn0fqqEno1ft4BcWmRFYRLDHv6ZgCyo6K+T0IGMORwvRDZ19RMI8putUUJ7gQO12vvSOQiysV2P+VdIKX4uRam9HQBHuQ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767864620; c=relaxed/simple; bh=MHhOHGsRzwofCR1asR1r+Dq8f8yikazgYrATxWvUMbA=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=Pun5Q3pkjd7AL1UyubkSj48lcCxn7IVgyY61n5+1RuRCqNw1AUiqiyL+2er6/1SyJWOiMjL4SJ33Hxh6b6ejCWHKCVsRlrDZfkCa+UV0HO8nLoczWQD+Tf+0yHePRq88RSDL86e4wdMBqp2sGR2RHhHCwNfxQKVKzyIKelBRd+c= 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=lgH3Ccy6; arc=none smtp.client-ip=209.85.210.175 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="lgH3Ccy6" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-7ade456b6abso2020487b3a.3 for ; Thu, 08 Jan 2026 01:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767864612; x=1768469412; 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=2BZj+c9peL3DJDhE+3l/bTa4UM4O6gj9bpwLXw91wmE=; b=lgH3Ccy6pF1pqHBAconMDBabWSCXjarBdsu+Zb5j3P46U2rLLUBg1MSsIUTemniExp tfF40sr+5HHMGku3bMHljHcyUgJKjYhTNmPYi1OlVw5aqU4B/PSVn5ZD5E3iN7fvXOqf AziXq1oQCGiys42UhvpOn2oW6zFOG4405sVzy5okYferCXWX86sSy+XBg9s29Dkn/Yld 8YWHOXZnik6Y09Z/efAbVFhIefCMsLW4Z6jIVSpgktiImT6H3Z/EVU3R4EV6KKkZGwGa 6R2ejLAYQM6HpiZHl8H9WXo+rG+93ZihCa+W2A0idRIdSmPAvlBueVLzPFgnX3xDuEsv ZDiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767864612; x=1768469412; 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=2BZj+c9peL3DJDhE+3l/bTa4UM4O6gj9bpwLXw91wmE=; b=TU6zrjHX8p3ABMYUbXmSH0ANQ0vr12ZL5iE1ld0bXp8v7NojRgT/Th7RhG7gVOaFz+ iuGDxagDR98I+PeGGGsENJOC0qz6RXrmf7JOqX2iv+kBdGVpnfe89tdcfD2bodA3Pkfe gGFd+dMRIqf3+YdlQ98GB7iXxXT7zv1pgu+A0hFVmQyVnVXgfKi6a5nQyB1fSH7xpALk 6vu8MYI4kjTUBoLE54xPFckCfmJBTfrRvVPzmK7bLdWST09nnnQUOu3obolBUt2TkdNf c9fomCCZUl4JXHl0UbT7RzrPzPCSCm31iGipjPVRDeVWvp0r22gZ7vaPOTlY5GcmLXxs vKrw== X-Forwarded-Encrypted: i=1; AJvYcCW97upf9w+wINYF9vYXoG/mM/Lc937UnhpbodLcAf20Ri/gqH21BgMNupLZS4z/LSGR3eZRn537QazAHHE=@vger.kernel.org X-Gm-Message-State: AOJu0Yz75gRLYJBCIokeiw/N4LCeDPBIx4jzYnEntCYylbjPjIGA7SBo ar1L8CM7xLnYYBlL2mFdk8Pbz1Wayfg/qa5RuyxbeZY2SH4Yjs+UvHIF X-Gm-Gg: AY/fxX6ZdHvbd78H9+yLtUyhdHCErxZDwzP0NDCqa8MVdM9qsyteSBETxuvH/+m6xfj HeDjNs5jUWNUHDCrKEsD6TeT/tJWJ6Qk1IrZCxg62PjXcZqXIQhfi3fOiZNKD09B+5h3kQf0ASz fHDfcYZkQ8VhnGl7sjpw0VAHzTao7YZp0w8lxJCpumxYby2XZ0IDl7YAcBlSUv/GIXu//qE4AzE 4w2mNRzUF1U4BetGOYnH6SEwUgael9l9j8WFhVjSHOMyViS1rqrW9WCKI2AM6ic4vX4Q8xkmwoi jRdgKCPYfEuMmWl0lF1t2buIKAqnTC6dnN6mcuBAfy4yJy+9Hj5d7vaw765oP6qOIJ/F/qI1icZ pliN76KdNPj40K1QwCdyAEZAYmSl67gwdLXmn2yWuRniLDH3fCsmVKnRgEZBCjQK9HEufJnW3/v rbYfjrJNW+LClLGC8rfJ0CFg== X-Google-Smtp-Source: AGHT+IFI05SxiqzyVxrtwlwkOSyv5QgkYxJTLKrxiL89jyMTQiggaVXS4Xp6MUQnnRzRml9tzxON7Q== X-Received: by 2002:a05:6a21:3297:b0:364:be7:6ffc with SMTP id adf61e73a8af0-3898f88ef78mr4557167637.18.1767864611947; Thu, 08 Jan 2026 01:30:11 -0800 (PST) Received: from [10.189.144.225] ([43.224.245.249]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c4cbf28f678sm7509050a12.3.2026.01.08.01.30.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 01:30:11 -0800 (PST) Message-ID: <96bae224-c971-44f6-94aa-eb0328021bc2@gmail.com> Date: Thu, 8 Jan 2026 17:30:07 +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> <243f57b8-246f-47e7-9fb1-27a771e8e9e8@gmail.com> Content-Language: en-US, fr-CH From: Sheng Yong In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/8/26 17:25, Gao Xiang wrote: > Hi Sheng, > > On 2026/1/8 17:14, Sheng Yong wrote: >> 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. > Hi, Xiang, > Just to make sure it's an invalid case (should not be used on > Android), yes? If so, thanks for the test on the APEX side. No, it's not a real use case, just an invalid case, and only used to test the error handling path. thanks, shengyong > > Thanks, > Gao Xiang > >> >> thanks, >> shengyong